automatic time zone offset computation is wrong

[Scotty]

Annoyance level bug. I connect from a machine in PDT Timezone, to a server (Linux, CentOS) in same PDT Timezone. FileZilla shows my times are an hour different. Both machines report they are PDT. For some reason, I can see at the beginning of the session this calculation (which is wrong):

Status: Calculating timezone offset of server...
Command: mtime "alp3"
Response: 1330985224
Status: Timezone offsets: Server: -28800 seconds. Local: -25200 seconds. Difference: 3600 seconds.

My Windows 7 Professional machine clearly states it is PDT, as well my Linux server reports the same.

[Alexander Schuch]

This is a duplicate of #4134.

[Alexander Schuch]

Okay, this is about the automatic timezone computation, whereas #4134 is about the server time offset configuration.

[Alexander Schuch]

Can you please provide a log? - ​http://trac.filezilla-project.org/wiki/TicketSubmissionGuide#Logs

Make sure it contains the raw directory listing, the "mtime" command (as shown in your original post) of a file available in the raw directory listing.

What is your local (client) timezone?
What date/time is shown on the remote directory view for a file in question (file check with "mtime" command)?

[Mike McAngus]

Hmm. A ticket opened 2 years ago (5237) as been marked as a duplicate for this one opened 4 days ago?

What annoys me is that there is no reference from this new ticket back to the older one one that was recently closed as a duplicate. This means that the information provided by shrimpwagon and me in ticket #5237 is not readily available as part of the history of this issue.

This is now an 8 year old (at least) issue, from ticket 2026 to 4134 to 5237 to 8171.

Hopefully, this history lesson will help spur someone on to figuring out and fixing this annoying problem that occurs annually.

[Scotty]

Log (cut-n-pasted from message log area) complete:

---

Status: Connecting to elite1407.inmotionhosting.com...
Response: fzSftp started
Command: open "root@…" 22
Command: Pass: *
Status: Connected to elite1407.inmotionhosting.com
Status: Retrieving directory listing...
Command: pwd
Response: Current directory is: "/root"
Command: ls
Status: Listing directory /root
Status: Calculating timezone offset of server...
Command: mtime "alp3"
Response: 1330985224
Status: Timezone offsets: Server: -28800 seconds. Local: -25200 seconds. Difference: 3600 seconds.
Status: Directory listing successful

---

Other questions:

What is your local (client) timezone?

--- PDT (Windoze reports: Pacific Time -08:00 on the control panel)

What date/time is shown on the remote directory view for a file in
question (file check with "mtime" command)?

--- Not sure, I don't know the mtime command in Unix, I see it in the FTP logs, you have that result. If I upload a file at 10:05a PDT on my machine, it reports the time stamp on the file as: 11:05a PDT on the remote machine (again, exactly 1 hour off even though both machines are clearly on PDT).

Is FileZilla possibly just missing the fact that my machine is on Daylight Savings? If you take that away, then yes, it would be on -07:00 wouldn't it? If this issue is that old (as old as reported in some comments) then it's likely something simple like that isn't it? Daylight savings is a switch in Windows, not an automatic thing when you go and ask the OS for the timezone, you gotta also ask if the Daylight Savings switch is on (or off) and then act accordingly (Daylight savings adding another hour to the delay from UTC). Just a thought...

Sorry, when I submitted this, I did a search for timezone and found nothing that seemed exactly related. Guess I was wrong...

[Alexander Schuch]

Can you please enable "show raw directory listing" in Settings -> Debug and attach the line logged for the filesystem object called "alp3" (used by mtime in your example).

[Alexander Schuch]

Command: mtime "alp3"
Response: 1330985224

That date refers to "Mon, 05 Mar 2012 22:07:04 UTC". This is I believe during PST (UTC-8). Your client is at PDT (UTC-7). It is possible for the client to detect its timezone (rather than just the current timezone offset). For the server however, that's not possible. UTC-8 could be normal time, another time with DST in effect or even yet another time with midsummer in effect (for example CEMT some decades ago).

So, based on what the client knows about the server, the calculation is correct.

And if you come up with the idea to not consider DST, simply imagine a file on the server created during DST…

[Stephen]

This is a very interesting problem. I discovered it myself just now, on a server that changed from EDT (GMT-4) to EST (GMT-5) in November. When FileZilla calculates the offset using an EDT file it's off by an hour (since we're now in EST), but when it uses an EST file the calculation is correct.

I'm curious why FileZilla doesn't use MTIME when available. It returns GMT and could be converted to the client's timezone without another offset. Is it a question of performance? If so perhaps the user could configure whether to use it.

[Ken Vickers]

Problem seems to be FileZilla assumes SFTP server changes the mod date on the home folder.

Command: pwd
Response: Current directory is: "/"
Command: ls
Status: Listing directory /
Status: Calculating timezone offset of server...
Command: mtime "edrive"
Response: 1379207417
Status: Timezone offsets: Server: 134700 seconds. Local: 3600 seconds. Difference: -131100 seconds.
Status: Directory listing successful
Status: Retrieving directory listing...

[Ken Vickers]

I should comment to say server is Windows Server in same timezone as client (BST)
Server running GlobalScape EFT

[Thorsten Lau]

I my opinion this issue is daylight saving time related, and the way the filezilla client guesses the timeoffset.

The client tries to guess the localtime offset of the sftp server my getting "mtime" of the most recent modified file in the accounts home directory.

If this file was last modified during a different daylight savings period this triggers the calculation of the wrong offset.

Example: (Timezone CET (Europe/Berlin), Daylight Saving Times Automation enabled on the Server)

$ touch -t 201410240000 testfile.dst
$ touch -t 201410280000 testfile
$ ls -ltr --time-style=full-iso
-rw-r--r-- 1 root root 0 2014-10-24 00:00:00.000000000 +0200 testfile.dst
-rw-r--r-- 1 root root 0 2014-10-28 00:00:00.000000000 +0100 testfile
$ date --rfc-3339=s
2014-10-28 18:01:00+01:00

Connect with the Filezilla Client:

---

---8< *snip* ---
Status: Calculating timezone offset of server...
Command: mtime "testfile"
Response: 1414450800
Status: Timezone offsets: Server: 3600 seconds. Local: 3600 seconds. Difference: 0 seconds.
---8< *snap* ---

---

$ rm testfile
rm: remove write-protected regular empty file `testfile'? yes
$ ls -ltr --time-style=full-iso
-rw-r--r-- 1 root root 0 2014-10-24 00:00:00.000000000 +0200 testfile.dst

---

---8< *snip* ---
Status: Calculating timezone offset of server...
Command: mtime "testfile.dst"
Response: 1414101600
Status: Timezone offsets: Server: 7200 seconds. Local: 3600 seconds. Difference: -3600 seconds.
---8< *snap* ---

I hope this clarifies the circumstances of this issue.

Solution: None that would work 100% of the time, since creating files at the remote site isn't always possible.

[Michel R.]

Hi, i found this bug and read the #4134...
In my opinion this bug appears because of #4134 and should be treated as a duplicate.
Resolving #4134 will solve this one too.

The problem is that the randomly tested file/directory for mtime has sometimes been created in the other 6 months period of the daylight savings settings, hence the wrong result of calculation resulting in a one hour offset, and not always appearing, but especially during the weeks after daylight savings settings change ;-)

Solutions suggested in my #4134 comment

Michel

[Tim Kosse]

This had already been fixed several versions ago.