Bug in date/time change of file

Discussion of bugs and problems found in Altap Salamander. In your reports, please be as descriptive as possible, and report one incident per report. Do not post crash reports here, send us the generated bug report by email instead, please.
User avatar
McLion
Posts: 74
Joined: 26 Apr 2006, 17:54
Location: Switzerland

Bug in date/time change of file

Post by McLion » 02 Nov 2010, 23:21

Changing a files creation or change date and time (Ctrl + F2) has one hour offset. Setting a time of 22.00.00 changes the file to 23.00.00 for instance.
This is on 2.54 german.

therube
Posts: 622
Joined: 14 Dec 2006, 06:22

Re: Bug in date/time change of file

Post by therube » 03 Nov 2010, 07:20

(Not seeing the issue on my end, EN. Tried disabling Daylight Savings Time adjustment, but that made no difference. Set a file to a time of 22:22 & then to 23:23 & each time the time was reflected as expected. DIR /TC {name} will show the Creation Time & that corresponds to what a subsequent Ctrl+F2 also shows <for me>.)
WinXP Pro SP3 or Win7 x86 | SS 2.54

User avatar
McLion
Posts: 74
Joined: 26 Apr 2006, 17:54
Location: Switzerland

Re: Bug in date/time change of file

Post by McLion » 03 Nov 2010, 10:03

I just double-checked on my office machine ... and its exactly the same.
Home is W7-64, Office is W7-32, both German and on UTC+1. Home does synchronize to web with automatic daylight saving. Office in in AD-Domain and gets time from AD Server.
Since I am on UTC+1, I assume it has something to do with that, its exactly the same offset. It does not only change to the wrong time, it also does show the wrong time when just invoking the dialog with Ctrl+F2.

Windows:
Win.jpg
Win.jpg (8.47 KiB) Viewed 8288 times
Salamander:
Sal.jpg
Sal.jpg (7.02 KiB) Viewed 8288 times

Jan Patera
Plugin Developer
Plugin Developer
Posts: 707
Joined: 08 Dec 2005, 14:33
Location: Prague, Czech Republic
Contact:

Re: Bug in date/time change of file

Post by Jan Patera » 03 Nov 2010, 10:13

McLion wrote:Changing a files creation or change date and time (Ctrl + F2) has one hour offset. Setting a time of 22.00.00 changes the file to 23.00.00 for instance.
This is on 2.54 german.
What kind of disk are you doing this on? NTFS? Local or remote? Did you restart Salamander since the Daylight time ended last weekend?

User avatar
McLion
Posts: 74
Joined: 26 Apr 2006, 17:54
Location: Switzerland

Re: Bug in date/time change of file

Post by McLion » 03 Nov 2010, 11:35

It's NTFS, local, internal SATA disk and yes restarted every morning.

Petr Solin
ALTAP Staff
ALTAP Staff
Posts: 1110
Joined: 08 Dec 2005, 09:13
Location: Novy Bor, Czech Republic
Contact:

Re: Bug in date/time change of file

Post by Petr Solin » 04 Nov 2010, 08:28

You are probably reporting difference between file time shown in Windows Explorer and Salamander. It is not connected to changing file time, it shows wrongly all times from summer period (e.g. Oct 1, 2010) in winter period and vice versa.

Explorer in Windows 7 newly shows correct time independently on current time (it shows the same time in summer and winter time period). Vista and XP show all summer times wrongly shifted one hour in winter and vice versa, it's also the reason why many compare utilities shows many differences when time is changed to winter or back to summer.

I have this problem already on my to-do list: we should use SystemTimeToTzSpecificLocalTime instead of FileTimeToLocalFileTime, maybe this explains the problem better:
FileTimeToLocalFileTime uses the current settings for the time zone and daylight saving time. Therefore, if it is daylight saving time, this function will take daylight saving time into account, even if the time you are converting is in standard time.

Jan Rysavy
ALTAP Staff
ALTAP Staff
Posts: 5196
Joined: 08 Dec 2005, 06:34
Location: Novy Bor, Czech Republic
Contact:

Re: Bug in date/time change of file

Post by Jan Rysavy » 04 Nov 2010, 08:43

DST HELL...

antp
Posts: 45
Joined: 27 Jan 2006, 22:18
Location: Bruxelles, Belgium
Contact:

Re: Bug in date/time change of file

Post by antp » 19 Jan 2017, 18:12

Hi,
I dig up this thread since it is the most recent one I found about this problem...
I'm surprised to see that the bug still exists in the current version... more than six years later :/
To be honest, I only discovered it recently. Was it introduced somewhere around that time (2010) ? Or was it already there before?
Possibly I never noticed it before Windows 7 if Microsoft only fixed that at that moment.
Hoping it will be in the next batch of bug fixes.

User avatar
SvA
Posts: 448
Joined: 29 Mar 2006, 02:41
Location: DE

Re: Bug in date/time change of file

Post by SvA » 20 Jan 2017, 20:15

There is no problem in Altap Salamander concerning this. Just checked again on Win10 x64 local NTFS disk; never experienced any problem setting time in AS on any OS, any filesystem. Using AS for many years (about 16 or so).

Rember though: Files seen from the other side of a DST time jump (forward or backward) behave differently, depending on whether the filesysten saves UTC (e.g. NTFS) or local time (e.g. FAT). It's a design dilemma (however you try to design your system, you break something). Microsoft decided on the way it currently is. Whatever date differences you experience in Salamander you will also experience in Windows Explorer.

antp
Posts: 45
Joined: 27 Jan 2006, 22:18
Location: Bruxelles, Belgium
Contact:

Re: Bug in date/time change of file

Post by antp » 20 Jan 2017, 20:27

I also have Win10 64-bit and a NTFS disk, and the "bug" is visible.

Now we are outside daylight change, so a file from this month has the same time in Windows Explorer & Salamander.
But if you take a file from the summer, there is 1h difference between the two programs.

The other way round, if you set the PC's clock to a date in summer, a file with a summer date has the same time in both programs, but a winter file will have 1h difference.

Note: if you are in southern hemisphere swap winter & summer in my post above :D

DST for the time of a file should be computed depending on the date of the file, not the current date.
In .NET it is rather easy to manage (at least since version 2 or 3) but with only Win32 API it may be more tricky (or maybe the functions mentioned by Petr does it?)

Petr Solin
ALTAP Staff
ALTAP Staff
Posts: 1110
Joined: 08 Dec 2005, 09:13
Location: Novy Bor, Czech Republic
Contact:

Re: Bug in date/time change of file

Post by Petr Solin » 20 Jan 2017, 21:17

Yes, new trend is to show local date & time valid in the moment of last write to file. It's better except moments from that one hour when we shift our watches back - from 3:00 to 2:00 = e.g. time 2:23 addresses two moments exactly one hour delayed and you cannot tell which one it was. Fortunately last write time in system is still in UTC, so you can use any compare function to find out if same displayed times 2:23 are the same moments or not.

I still have this on my to-do list, but it still doesn't have such priority to be implemented.

User avatar
McLion
Posts: 74
Joined: 26 Apr 2006, 17:54
Location: Switzerland

Re: Bug in date/time change of file

Post by McLion » 03 Apr 2017, 11:40

Yup. Still seeing it too.
Files created two weeks ago before DST show one hour later in Salamander.
I.e.: in Explorer: 05.00 shows as 06.00

Even if this has no priority .. a known bug from 2010 and still there ?!? :shock:

Petr Solin
ALTAP Staff
ALTAP Staff
Posts: 1110
Joined: 08 Dec 2005, 09:13
Location: Novy Bor, Czech Republic
Contact:

Re: Bug in date/time change of file

Post by Petr Solin » 03 Apr 2017, 12:17

I don't think this is bug it is just older solution (before Windows 7 it was widely used). We will change it to show times as Explorer.

Post Reply