It's not as simple as this. My conclusion: Broken RFC.
I too experience the problem where the timezone difference calculation gives ridiculous results. Here's why.
The FTP client uses the MDTM command to retrieve the mtime of a file in UTC - and this works 100% correctly.
However the FTP client has no reliable way of getting the mtime of a file in the server's local time zone
. The FTP client thinks
that it does but it doesn't. The FTP client uses the LIST command. In the output of this command it locates the line for the file that it used MDTM on. It parses out the time and it subtracts. The problem with this is that RFC 959 says:
Since the information on a file may vary widely from system to system, this information may be hard to use automatically in a program, but may be quite useful to a human user.
The RFC seems to be completely silent on what information is returned. Convention says that it is the same as the output from 'ls -al' but that does not appear to be present in the RFC. Hence a server is not broken if it does not do this.
(Later RFCs added the MLST command, which solves the problem of clients thinking that they know what to do with the output of the LIST command, but unfortunately the MLST command only returns the mtime in UTC, as far as I could tell.)
The actual problem for me appears to be that the FTP server is not sending the mtime in the output from LIST. The file system that the FTP server uses has any number of different times that are maintained and the FTP server just has to pick one for the LIST command. If it doesn't pick the same time field that it uses for MDTM then the subtraction gives very dubious results.
As far as I can see, there is no way to get the mtime in server local time and no way simply to ask the server for its current time zone offset from UTC.
So I can only echo those who suggest that "Adjust server timezone offset" should allow an additional choice that makes it "Override" rather than "Adjust". That won't be ideal but it is a lot better than "millions of seconds".
If you won't entertain that suggestion then control over the exact
file that is used for the timezone difference calculation would probably allow me to work around the problem.
Another general issue is that the whole approach of subtracting two times only tells you what the server's time zone offset from UTC was
at the time that the file was modified or whatever. If the file that the FTP client picks was modified or whatever some time ago and in the mean time the server has changed on or off DST, as appropriate, then the displayed times are wrong. Again, control over the exact
file being used would allow me to work around that.
FTP client is FileZilla 3.7.3 on Ubuntu 13.10 x86_64, but the same misbehaviour occurs with FileZilla on Windows.