Hi Paul, > Your latest message prompted me to search microsoft.com further, and I > found this: > > https://support.microsoft.com/en-us/help/190315
Excellent finding! Thank you. > I wonder whether Cygwin deals with this problem? Cygwin's stat() implementation converts the times (from FILETIME to time_t) in a very simple way: by adding the number of seconds from 1601-01-01 to 1970-01-01. Whereas the MSVC stat() apparently does computations that depend on the time zone. > which says that the glitchy behavior is "by design" (!) This "design" is probably the backward compatibility with the old times when 1. most computers were not connected to the Internet, and thus could not connect to an NTP server, 2. the OS did not contain the time zone and DST dates database, thus it was the responsibility of the user to modify the time zone twice a year. > and occurs in NTFS but not FAT (!!). This is not true (anymore?). The effect exists also on FAT32, just like on NTFS. Here's the experiment on NTFS: $ ./stat-file-cygwin.exe n.txt t.tar File n.txt mtime = 17261 1 2961 File t.tar mtime = 17132 18 1920 $ ./stat-file-msvc.exe n.txt t.tar File n.txt mtime = 17261 2 2961 File t.tar mtime = 17132 19 1920 $ ./stat-file-mingw.exe n.txt t.tar File n.txt mtime = 17261 2 2961 File t.tar mtime = 17132 20 1920 and on FAT32: $ ~/stat-file-cygwin.exe n.txt t.tar File n.txt mtime = 17261 1 2962 File t.tar mtime = 17132 18 1922 $ ~/stat-file-msvc.exe n.txt t.tar File n.txt mtime = 17261 2 2962 File t.tar mtime = 17132 19 1922 $ ~/stat-file-mingw.exe n.txt t.tar File n.txt mtime = 17261 2 2962 File t.tar mtime = 17132 20 1922 In both cases, with the notation local_time = utc_time + zone_offset + dst, you have - in Cygwin: mtime = utc_time - in MSVC: mtime = utc_time + zone_offset - in mingw: mtime = utc_time + zone_offset + dst_now - dst > Perhaps we should just advise NTFS users to not click the box saying > "Automatically adjust clock for daylight saving changes" in their > MS-Windows preferences. I don't think this is a good advice because it means that * Either the user's time display ignores DST (which is desirable only for some farmers opposed to DST), or it's the user's responsibility to change the time zone twice a year (which most users will find annoying nowadays). * The bug is still not fixed. Here's the experiment with "Adjust for daylight saving time automatically" disabled: In German timezone: $ ./stat-file-cygwin.exe n.txt t.tar File n.txt mtime = 17261 1 2961 File t.tar mtime = 17132 18 1920 $ ./stat-file-msvc.exe n.txt t.tar File n.txt mtime = 17261 1 2961 File t.tar mtime = 17132 19 1920 $ ./stat-file-mingw.exe n.txt t.tar File n.txt mtime = 17261 1 2961 File t.tar mtime = 17132 19 1920 In Israel timezone: $ ./stat-file-cygwin.exe n.txt t.tar File n.txt mtime = 17261 1 2961 File t.tar mtime = 17132 18 1920 $ ./stat-file-msvc.exe n.txt t.tar File n.txt mtime = 17261 2 2961 File t.tar mtime = 17132 20 1920 $ ./stat-file-mingw.exe n.txt t.tar File n.txt mtime = 17261 2 2961 File t.tar mtime = 17132 20 1920 So, in this case, with the notation local_time = utc_time + zone_offset + dst, you have - in Cygwin: mtime = utc_time - in MSVC: mtime = utc_time + zone_offset - dst - in mingw: mtime = utc_time + zone_offset - dst I think, if we want a sane behaviour, we have no choice than to override stat() and fstat(). Bruno
