Server time zone offset is incorrect

[Stig Arne Bye]

I've discovered a bug in the server timezone offset settings.

The following table show my test results when trying to use different timezone offsets in FileZilla server preferences (Server Administration - Advanced tab).

Table columns
-------------
Local time:     Local computer time.
Setting:        Server timezone offset setting in FZ preferences.
Server time:    Server time shown AFTER adjusting timezone offset.
Actual offset:  The actual timezone offset using current setting.

                                      Actual
  Local time   Setting   Server time  offset
  ----------   -------   -----------  -------
   [...]
   12:00:00      -5 h     06:00:00      -6 h
   12:00:00      -4 h     07:00:00      -5 h
   12:00:00      -3 h     08:00:00      -4 h
   12:00:00      -2 h     09:00:00      -3 h
   12:00:00      -1 h     10:00:00      -2 h
   12:00:00       0 h     11:00:00      -1 h
   12:00:00      +1 h     13:00:00      +1 h
   12:00:00      +2 h     13:00:00      +1 h
   12:00:00      +3 h     14:00:00      +2 h
   12:00:00      +4 h     15:00:00      +3 h
   12:00:00      +5 h     16:00:00      +4 h
   [...]

As seen from the above, when the offset is set to "0", the server time is shown as one hour behind, and using either "+1" or "+2" will both show the server time as one hour ahead...

This bug is present in FileZilla 3.1.6, but was also noticed in previous versions...!

[Tim Kosse]

I cannot reproduce this problem.

Please attach an individual log file with debug level set to 3 and enabled "show raw directory listing" for each offset.

[Stig Arne Bye]

Strange, as now I cannot reproduce this problem either.....

However, It's still a true fact that I DID several tests that gave the same and strange behaviour as mentioned in my report.

I first discovered this behaviour with FZ 3.1.5, where I tried different timezone offset settings and carefully made notes of every change made and the result this produced (from these notes I then compiled the table in my report).
Then I downloaded and installed FZ 3.1.6, and did exact similar tests with this version, and with the exact same results as with version 3.1.5...

[Sandya]

i am using 3.1.6 version.
I have date/time set to system default in the client setting.
But the time in filezilla seems to totally different than that of my system.
Is it related to this defect logged?

[Emily]

I'm seeing this issue as well on a daily basis when connecting to our corporate fileserver via SFTP. This does NOT occur when connecting over FTPES.

From my normal level of log:

Status: Calculating timezone offset of server...
Command: mtime "CNIB"
Response: 4294952895
Status: Timezone offsets: Server: 1243538220 seconds. Local: -14400 seconds. Difference: -1243552620 seconds.

So obviously my local offset is not being calculated correctly at all. This results in all the timestamps on the server being dated as 1969 or 1970... month and day are off as well of course. Slightly confusing.

I am attaching a level 3 debug report as per your instructions.

[Emily]

Log of odd timetravelling timezone offset issue.

[vodoomoth]

I am also experiencing this bug in FileZilla Client 3.5.3 on a Windows 7 Home Premium 64-bit SP1 (NT 6.1 build 7601, SP1) system.

The server timezone offset in the advanced preferences of a server in Site Manager is not correctly honored when displaying server file times.

Suppose the modification time on a file on my local system is 13:00. Immediate upload lasts less than 2 seconds. The server I'm connected to shows the file timestamp as 12:00. Which means for me that I need to set +01:00 as the server timezone offset in the advanced preferences of Site Manager. Right?

Here is what happens:
offset -03:00 => server time changes to 10:00. I'm expecting 09:00.
offset -02:00 => server time changes to 11:00. I'm expecting 10:00.
offset -01:00 => server time remains at 12:00. I'm expecting 11:00.
offset +01:00 => server time changes to 14:00. I'm expecting 13:00.
offset +02:00 => server time changes again to 14:00. Correct.
offset +03:00 => server time changes to 15:00. Correct.

That's very annoying especially in places where DST is in effect.

Happens with FileZilla Client 3.5.3. I'm pretty certain it didn't happen with v3.5.2

Btw, I only connect to one server so I can't be mistaking servers.

[Alexander Schuch]

Another small example is available in duplicate #8171.

[Alexander Schuch]

Replying to syndaryl:

I'm seeing this issue as well on a daily basis when connecting to our corporate fileserver via SFTP. This does NOT occur when connecting over FTPES.

From my normal level of log:

Status: Calculating timezone offset of server...
Command: mtime "CNIB"
Response: 4294952895
Status: Timezone offsets: Server: 1243538220 seconds. Local: -14400 seconds. Difference: -1243552620 seconds.

So obviously my local offset is not being calculated correctly at all. This results in all the timestamps on the server being dated as 1969 or 1970... month and day are off as well of course. Slightly confusing.

I am attaching a level 3 debug report as per your instructions.

This bug is about server timezone offset configuration. You are referring to #8171 about automatic timezone offset computation.

[Alexander Schuch]

The offset is applied to the time send by the server.

Please see ​http://wiki.filezilla-project.org/Server_timezone_offset for an example.

So from how I understand this, a file reported with modification time 13:00 and a configured server timezone offset of -03:00 will be shown as 10:00.

Can you please provide a log with raw directory listing enabled?
What's your current (client) time and timezone?
What's your server timezone offset configuration?
What time is displayed for the files listed in raw directory listing?

[vodoomoth]

Replying to ci-dev:

The offset is applied to the time send by the server.

Please see ​http://wiki.filezilla-project.org/Server_timezone_offset for an example.

So from how I understand this, a file reported with modification time 13:00 and a configured server timezone offset of -03:00 will be shown as 10:00.

Can you please provide a log with raw directory listing enabled?
What's your current (client) time and timezone?
What's your server timezone offset configuration?
What time is displayed for the files listed in raw directory listing?

IMHO, the problem is much simpler than what would require these questions be answered. I don't have the answers so I'll let other people give them.

The real issue, to me, is that the formula that FileZilla uses seems to change depending on the value of Server Timezone Offset. This can be seen in my previous comment (#5) and in the ticket opening comment.

[gsosna]

I found a problem where server time and client time are identical, but the calculation shows -3600 seconds, because when it issues command "mtime" it uses a file created last week, when DST was in place. This week, however, DST is no longer in place. So instead of using an existing file, FileZilla should be creating its own temporary file to decide the offset rather than using an older file... does this make sense?

Status: Calculating timezone offset of server...
Command: mtime "manage_update.log.20140405"
Response: 1396693801
Trace: CSftpControlSocket::ListParseResponse(1396693801)
Status: Timezone offsets: Server: 46800 seconds. Local: 43200 seconds. Difference: -3600 seconds.

[Michel R.]

Hi,
thank you gsosna for your explanation. I'm regularly striving on this problem for years, tipycally twice a year... after daylight savings changing ;-) But it randomly occurs on some servers or folders. Now I understood why : because FZ checks for mtime of a random file/folder which can eventually have been created in the other daylight sayving setting period.

The solution of creating a temp file isn't always available : you sometimes only have read permissions when landing in a server folder.

I would suggest two options :

• offering the user a way to recheck the timezone setting once he has noticed an inconsistency, hopefully testing on a better file/folder (and the user could be allowed to test on THIS file/folder)
• making FZ more consistent in the file/folder it chooses : either the first or the last of the directory list. So that we could eventually consistently trick him by touching an appropriately named file.

... and a third : ftp mode never fails. I don't know how the server offset is calculated, but if there would be a possibility to compute it the same way it would also be an option.

[Tim Kosse]

This had already been fixed several versions ago.