Timezone offset calculation error

[ericF]

When I connect to my web server (set to Eastern Time, as is my workstation), I get the following result:

Status: Calculating timezone offset of server...
Command: mtime "abc"
Response: 4294949295
Status: Timezone offsets: Server: 1210555801 seconds. Local: -18000 seconds. Difference: -1210573801 seconds.
Status: Directory listing successful

If I try to run the mtime command from the custom command dialog, I get "command not supported by this protocol". We are using an SFTP server on the web server side. Of course, with the excessive offset calculated, all of my remote filedates show up in the early 1970's. I really don't think I can fix the timezone offset by 35 years...

Any suggestions?

Eric

[botg]

Broken server.

Command: mtime "abc"
Response: 4294949295

See http://www.openssh.com/txt/draft-ietf-s ... fer-02.txt

The server is supposed to return the modification time in seconds since 1970-01-01 UTC.

4294949295 corresponds to some time in 2106, so the server has a positive timezone offset of almost 100 years.

Note that times before 1970 cannot be represented using SFTP. Even reinterpreting the result as signed 32bit integer would place the file somewhere around 1902 or so, which would clearly make it a very late Y2K issue.

[ericF]

Thanks - I assume it's the SFTP server that's broken - it's freeware,so maybe they didn't implement mtime correctly.

Is there a way to prevent FileZilla from attempting to determine the timezone offset, and just let the timestamps go back and forth between local and remote (where they are matched in this case)?

Or, can you recommend an SFTP server solution for Windows Server 2003? Is Filezilla Server ready for production use?

ef

[botg]

Or, can you recommend an SFTP server solution for Windows Server 2003?

The OpenSSH port in Cygwin, works just fine, I am using it myself occasionally.

Is Filezilla Server ready for production use?

It does not support SFTP.

[zillarian]

It maybe a broken server but it's strange:
On OS X with Cyberduck I have absolutely no problem. Time is displayed correctly. Fillezilla on Windows calculates a timezone offset and displays all remote file dates as of 1970.
My sftp server works apart from this perfectly and the best solution for this problem is to allow to disable the timezone offset calculation in the server configuration. The server is capable to transmit "acceptable" dates. Cyberduck proves that. To tell people to change their servers is not always possible. Should be easy to implement a simple checkbox:
enabled: calculate timezone offset
disabled: bypass timezone offset calculation

Thanks.

[botg]

Simple radio button:
[x] Use a proper server
[ ] Do not use a broken server

[zillarian]

That's not a serious reply. The server works with other sftp clients perfectly. I'm not able to change the server installation. I'll have to take what is offered. I can recommend to install another server but the fact remains that I would appreciate to be able to deactivate the timezone offset calculation. Cyberduck works perfectly with the sftp server and I can understand that you'd like to maintain a standards compliant function, just make it optional.

[botg]

FileZilla works perfectly with standards compliant servers. So where's the problem? Certainly not on my end.

[zillarian]

I've never said that the problem is on your side. My problem is that I cannot change the sftp server of my customer. I'm using Filezilla but I have this problem caused by the sftp server software. If Filezilla allowed to switch off this feature the problem would be solved for me and maybe for some others. Once again: I can change my ftp client but not my ftp server. I love Filezilla. If you're not willing to implement this feature just let me know and I will test some other sftp clients for Windows to see whether I encounter the same problems. Once again: I'm asking for help.

[supposer]

zillarian is not asking you to change its behavior, just make the feature optional. One of the pluses of Filezilla has always been that it is configurable.
It shouldn't do something like that automatically without the option to turn it off.
Filezilla developers are beginning to sound very "Microsoftish" if their replies take the tone that "we know what you need better than you do."
This same kind of response appeared when users requested the old Filezilla feature of turning off the remote file cache (basically F5 refreshing on every view of a directory) They were essentially told to go jump.

Complaints about Filezilla's attitude aside, what about the site manager offset setting? If you set this to your desired value (+1hr, -1, 0, etc.), does it suppress and/or override the automatic (MDTM or mtime) setting? Or does it get overridden by the auto setting? If the latter, it would be just another example of my complaint above. (Actually, I think it is overridden if your entry is zero, so make it plus or minus 1 minute, and you might be good)
So I'm holding out hope that a site manager entry with +- 1min gets zillarian a solution.

[botg]

Please note that mtime is not only used for calculating the timezone offset. It is also used in other situations to obtain the file time when for example a full listing is not desired. As such, a server that returns an incorrect mtime will lead to additional problems aside from the timezone offsets.

Filezilla developers are beginning to sound very "Microsoftish" if their replies take the tone that "we know what you need better than you do."

For every problem there are two types of solutions. The good ones and the "Microsoftish" ones. In this case, your server is broken and violating the SFTP specifications.

The Microsoftish solution would be to simply ignore the standards and do some extremely incompatile custom stuff. The result would be a total mess. Remember the days of old when the only widely use browser was the standards incompliant IE? 99.9% of all websites were violating the HTML specifications. Displaying those pages in a standards compliant browser was impossible.

The good solution on the other hand is to refuse to work with such broken servers. Elegant, simple and does not violate the specificatins.

Complaints about Filezilla's attitude aside, what about the site manager offset setting? If you set this to your desired value (+1hr, -1, 0, etc.), does it suppress and/or override the automatic (MDTM or mtime) setting?

The custom offset is added on top of the automatic offset.

[daystrom]

Greetings, I ran into a similar problem recently and in my case the source of the problem looks to be how Windows handles Daylight Savings Time, not the server.

Just last week prior to the most recent DST change everything was working correctly when connecting to my Linux server via SFTP using Filezilla on Windows XP, the offset for the server and local matched. However right after the DST switch this past weekend there was a difference of 3600s (1hr) (Server: -18000 vs Local: -14400) even though the clocks matched when I checked from the command prompts on both machines.

To fix the problem in Windows I went to the time zone settings and unchecked "Automatically adjust clock for daylight saving changes" and manually set the correct time. This eliminated the discrepancy from the mtime in Filezilla so that now server: -18000 & Local: -18000.

Funny that in the previous posts all assumed the freeware SFTP server or Filezilla needed to be fixed or tweaked when the problem looks to be with the automatic DST feature in WinDOS

This could also explain why the problem appeared then disappeared as described in Ticket #4134 (Server timezone offset is incorrect) if the tests were done straddling a DST change.

[botg]

DST handling is a known problem that's totally different from the problem the original topic creator had.

[ftpper]

Broken server.

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.

Edit:

FTP client is FileZilla 3.7.3 on Ubuntu 13.10 x86_64, but the same misbehaviour occurs with FileZilla on Windows.

[botg]

ftpper, this topic is about SFTP.

As for your completely unrelated issue with FTP's LIST command, the solution is already there and so simple: Upgrade to a server that supports MLSD. Every decent server not older than 6 years has this command.