yes, this did work before I upgraded to version 57

We switched to assuming FTP times were in UTC instead of the local time zone in https://chromium.googlesource.com/chromium/src/+/27f05072359d1862332f695ef9530f5f19da8b76.  The switch was mostly motivated by https://crbug.com/666535, but since FTP provides no way to specify time zone, one way or the other, and there's no spec, doesn't seem to be an unreasonable change.

Hello,  so, if I understand the latest reply, you're saying the 666535 bug fix was reasonable.  What I'm uncertain about is if you're going to fix it so it works that way it did prior to version 57?  It should display the file date timestamp on the server.

FTP provides no mechanism to know what timezone the server is in.  So it's logically impossible to be certain what the timestamp on the server is, in local time.  We've switched to assuming it's GMT, since we don't have access to the local expanded time to a POSIX time in the renderer process on Linux.  (Curiously, we can apparently convert a POSIX time to a formatted local time).

There are no plans to fix this.

So, if it's logically impossible to be certain about the timestamp on the server, why would you then convert to an even more uncertain time?

Because we have no notion of "server time" once we've parsed a remotely received time, and, as I said, we have no access to the methods to convert from a string local time to GMT, so we can't assume it's local time without some workaround for sandboxing on Linux.

Also worth noting that FTP isn't actively maintained, so as long as something's not completely broken (Like the old code was on Linux), fixing it is low priority, though we'd certainly affect third party patches.

but it wasn't broken for Windows until the Linux fix was introduced.  why can't you determine the OS and display accordingly?

Thanks for the report!

You are correct that the behavior has changed in Chrome, however this was intentional.

As Matt described, FTP does not accurately describe timestamps for file listings.  All we have available is the calendar date reported by server, but without actually knowing what the server's timezone is!

So what browsers do is guess.

Firefox, and previous versions of Chrome, would interpret the calendar date using your local timezone. This of course is wrong, since it means if you have viewers from N different timezones, at most 1 of them will be seeing the "real" time. The closer your local timezone is close to the server's time zone, the closer your guess is.

Recent versions of Chrome show the date relative to the UTC timezone. This makes the time skew at least consistent regardless of your local timezone. It also means the maximum error is around 16 hours, whereas with the local timezone approach you could be as much as 32 hours off.

Both approaches are ultimately wrong and just guesses. Since they are both wrong, I see no reason why we should favor doing a different approach on Windows than Linux.

(Clarification: Disregard the 16 vs 32 hours remark, as written it is not correct).

Thanks and I understand your argument.   I don't agree with "so what browsers do is guess".  what Firefox and Edge and IE do is simply display what the server gives them, like Chrome used to do.

eroman@ mmenke@: Maybe we can file a bug to the spec or discuss with other browser vendors to assume UTC timezone as well for the sake of interop? Or it is just too much trouble?

FTP doesn't actually have a spec for directory format - it's just sent in the platform's native format, generally, and as a result, FTP clients have a dozen parsers for different and often obscure directory formats that I'm shocked are still around.

We don't really care enough about FTP to drive any work on standardization here, and I don't think you'll find much interest in other browser vendors, either, given that it isn't part of the web platform.