bug#32902: Add support for (TIMESTAMP . RESOLUTION) Lisp timestamps

[Eli Zaretskii]

> Cc: 32902@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 7 Oct 2018 22:18:12 -0700
> 
> > Microsoft made an incompatible change in its runtime libraries
> > around Windows Vista, and switched to 64-bit time_t even on 32-bit
> > systems.  Since we still try to support older Windows versions, we
> > must use that kludge, and we must limit ourselves to 32-bit time_t in
> > 32-bit builds.
> 
> Here are some possible suggestions:
> 
> 1. Redefine 'struct timespec' and 'clock_gettime' on 32-bit MinGW so that 
> they 
> use 32-bit time_t only. The redefinitions would be visible only within Emacs; 
> you wouldn't actually change MinGW.
> 
> 2. Have Emacs w32*.c detect the width of the MS-Windows API's time_t at 
> runtime, 
> and if necessary convert between any 32-bit time_t on the MS-Windows side and 
> the 64-bit time_t visible to the rest of the Emacs C code.
> 
> 3. Build one Emacs executable for 32-bit MS-Windows Vista and later (with 
> 64-bit 
> time_t), and another one for 32-bit MS-Windows XP and older (with 32-bit 
> time_t).
> 
> Any of these would insulate the rest of Emacs from this glitch.

The last two are undesirable, since it is generally expected of a
single Windows binary to run on all supported systems; having 2
separate binaries is possible, but complicates the matters.

I will try to look into the first alternative, not sure if its
feasible.

> > drop support for older Windows systems.
> 
> Microsoft itself has dropped support for the older MS-Windows systems in 
> question, and it would be fine if Emacs dropped support too. We routinely 
> drop 
> support for obsolete and no-longer-maintained operating system versions like 
> RHEL 5 and Irix 6.5.

I don't think we should follow Microsoft in their decisions.  Last
time this came up, we decided not to drop support even for Windows 9X,
and here we are talking about XP and older.  We still have a few years
to make that decision.