Opened 9 years ago

Last modified 6 years ago

#5338 new Feature request

Inconsistent timestamps for remote files during summer time

Reported by: BurninLeo Owned by:
Priority: normal Component: FileZilla Client
Keywords: Summer Time, Daylight Saving, Timestamp Cc: burninleo@…
Component version: Operating system type: Windows
Operating system version: Windows XP, Windows Vista, Windows 7

Description

Hi! In FileZille 3.3.2.1 (portable as well as installed version) I encounter a bug if the local and the remote computer have set a summer system time (daylight saving, timezone CEST).

This bug is a bit annoying when comparing the files. The files on the server always seem an hour "newer". The bug randomly does not occur (about 30% of my FileZilla runs), but I was unable to find out the pattern.

After uploading a file, its timestamp ist set correctly (if checked via ls -l), but the files view in FileZilla tells me that the file was an hour newer.

Change History (5)

comment:1 Changed 9 years ago by Edward F Eaglehouse

The time offset affects files being transferred in both directions. The file transferred to the remote server displays an hour newer. The file transferred to the local client ends up an hour older. My experience has consistently resulted in erroneous timestamps. My time zone is EST5EDT.

I am using FileZilla 3.3.2.1 on a Windows Vista 32-bit platform. Server is Solaris 10 over SFTP using OpenSSH 5.3p1. I use only released builds. If memory serves correctly, I recall encountering this bug for at least the past 3 releases.

comment:2 Changed 8 years ago by Rod Lockwood

If one party is using standard time and the other is using daylight savings even if they are in the same "timezone" these two are considered different times. You need to follow the instructions and set the site manager to compensate for the time difference. The instructions do not state if the "timezone differs". They state if the "time differs".

So, are you setting the site manager to allow for the difference between ST and DST? If you are, then there is a problem.

comment:3 in reply to:  2 Changed 8 years ago by BurninLeo

Replying to White Phoenix:

Thank you for the hint on summer time trouble! If an offset of one hour is set in the connection settings, most date-related inconsistencies disappear.

However, this can solve the problem only to some part. Actually both systems are working in summer time, but while the local Windows XP (accessing a FAT disc) seems to compensate for this in FileZilla Client, the remote Linux systems seems to deliver "uncorrected" timestamps. When connecting from Windows Vista to the same system, no such inconsistencies appear.

I guess that a lot of bad behaviors come together when things are about summer time...

comment:4 Changed 8 years ago by Rod Lockwood

This is one of many reasons why I believe the use of Daylight Savings Time should be discontinued.

comment:5 Changed 7 years ago by BurninLeo

Cc: burninleo@… added
Operating system version: XP, VistaWindows XP, Windows Vista, Windows 7
Summary: Wrong timestamp shown for remote files in summer timeInconsistent timestamps for remote files during summer time
Type: Bug reportFeature request

After 3 years, summer time issues bother me again twice the year - especially in FileZilla (Portable) Client. Depending on the filesystem Windows dates the files an hour earlier or not - and chaing the offset every time is nasty.

Here is a constructive idea how to easily solve the issue: Add a checkbox "auto" next to the offset settings. If checked, filezilla could upload a dummy file after connecting, set the time/date, check the difference, and update the connection settings. If there are concerns about access rights: Add an "adjust" button in the menu that does an reality check on time differences.

It seems that daylight saving will not be abolished soon. Therefore, I think this little function could increase the great comparison feature even more.

Note: See TracTickets for help on using tickets.