Page 1 of 1

Bug in date/time change of file

Posted: 02 Nov 2010, 23:21
by McLion
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.

Re: Bug in date/time change of file

Posted: 03 Nov 2010, 07:20
by therube
(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>.)

Re: Bug in date/time change of file

Posted: 03 Nov 2010, 10:03
by McLion
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 18131 times
Salamander:
Sal.jpg
Sal.jpg (7.02 KiB) Viewed 18131 times

Re: Bug in date/time change of file

Posted: 03 Nov 2010, 10:13
by Jan Patera
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?

Re: Bug in date/time change of file

Posted: 03 Nov 2010, 11:35
by McLion
It's NTFS, local, internal SATA disk and yes restarted every morning.

Re: Bug in date/time change of file

Posted: 04 Nov 2010, 08:28
by Petr Solin
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.

Re: Bug in date/time change of file

Posted: 04 Nov 2010, 08:43
by Jan Rysavy
DST HELL...

Re: Bug in date/time change of file

Posted: 19 Jan 2017, 18:12
by antp
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.

Re: Bug in date/time change of file

Posted: 20 Jan 2017, 20:15
by SvA
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.

Re: Bug in date/time change of file

Posted: 20 Jan 2017, 20:27
by antp
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?)

Re: Bug in date/time change of file

Posted: 20 Jan 2017, 21:17
by Petr Solin
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.

Re: Bug in date/time change of file

Posted: 03 Apr 2017, 11:40
by McLion
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:

Re: Bug in date/time change of file

Posted: 03 Apr 2017, 12:17
by Petr Solin
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.