Re: what shall we do with the drunken time_t ?

[Bruno Haible]

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