Opened 7 years ago

Closed 4 years ago

#8171 closed Bug report (fixed)

automatic time zone offset computation is wrong

Reported by: Scotty Owned by:
Priority: normal Component: FileZilla Client
Keywords: time zone offset Cc: stepheneliotdewey@…, ben@…
Component version: Operating system type: Windows
Operating system version: 7 Professional (Build 7601: SP1)

Description (last modified by Tim Kosse)

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.

Change History (16)

comment:1 Changed 7 years ago by Alexander Schuch

Resolution: duplicate
Status: newclosed

This is a duplicate of #4134.

comment:2 Changed 7 years ago by Alexander Schuch

Resolution: duplicate
Status: closedreopened
Summary: Computes Wrong TimeZone In Windowsautomatic timezone offset computation is wrong

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

comment:3 Changed 7 years ago by Alexander Schuch

Status: reopenedmoreinfo_reopened

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)?

comment:4 Changed 7 years ago by Mike McAngus

Status: moreinfo_reopenedreopened

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.

comment:5 Changed 7 years ago by Scotty

Operating system version: 7 Professional7 Professional (Build 7601: SP1)

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...

comment:6 Changed 7 years ago by Alexander Schuch

Status: reopenedmoreinfo_reopened

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).

comment:7 Changed 7 years ago by 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…

comment:8 Changed 7 years ago by Alexander Schuch

Status: moreinfo_reopenedreopened

comment:9 Changed 7 years ago by Stephen

Cc: stepheneliotdewey@… added
Keywords: offset dst daylight added

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.

comment:10 Changed 7 years ago by chiron80

Cc: ben@… added

comment:11 Changed 6 years ago by 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...

comment:12 Changed 6 years ago by Ken Vickers

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

comment:14 Changed 6 years ago by Alexander Schuch

Keywords: time zone added; timezone windows 7 dst daylight removed
Summary: automatic timezone offset computation is wrongautomatic time zone offset computation is wrong

comment:15 Changed 5 years ago by 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.

comment:16 Changed 4 years ago by 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

comment:17 Changed 4 years ago by Tim Kosse

Description: modified (diff)
Resolution: fixed
Status: reopenedclosed

This had already been fixed several versions ago.

Note: See TracTickets for help on using tickets.