Opened 15 years ago
Last modified 11 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 by , 15 years ago
follow-up: 3 comment:2 by , 13 years ago
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 by , 13 years ago
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 by , 13 years ago
This is one of many reasons why I believe the use of Daylight Savings Time should be discontinued.
comment:5 by , 12 years ago
| Cc: | added |
|---|---|
| Operating system version: | XP, Vista → Windows XP, Windows Vista, Windows 7 |
| Summary: | Wrong timestamp shown for remote files in summer time → Inconsistent timestamps for remote files during summer time |
| Type: | Bug report → Feature 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.
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.