Rob Janssen wrote:
So no, I don't expect a timestamp for a file to change when DST goes
into effect. On Unix/Linux, it doesn't. I was surprised to see that
it /did/ change in Windows, and I have seen several problems with it
(especially in the days that Pre-NT versions were still common)
It's a bug in the filesystem functions on Win32.
The routines were written to support FAT32 - which is entirely local
time based.
In NTFS it stores the UTC value on the filesystem.
So what happens is:
FAT32:
GetFileTime: Correct Local Time -> Incorrect UTC (using broken conversion)
FileTimeToLocalFileTime: Incorrect UTC -> Correct Local Time (using
inverse of broken conversion)
Works! Because the two bugs cancel each other out.
NTFS:
GetFileTime: Correct UTC (stored by filesystem)
FileTimeToLocalFileTime: Correct UTC -> Incorrect Local Time
Fails because the buggy conversion is only applied once.
Also due the the way the stat() function was written to 'correct' for
the bug in GetFileTime() it actually breaks NTFS.. making the problem worse!
MS have known about this bug for years (eg. Q158588) have not fixed it.
Pretty much every app that relies on timestamps on Win32 now uses
replacement functions to get the times (For NTFS basically you call
GetTimezoneInformation, work out when DST starts/ends and whether to
apply the DST correction, and manually apply it. There are replacement
stat() functions etc. that handle this freely available. I've not seen
them but I expect people have written similar functions for .net etc.).
Tony
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
