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 13:05:58 -0700
> 
> > I fixed it, but please take a look, perhaps there's a better fix for
> > this situation.
> 
> That's only a very partial fix, unfortunately. I looked into the matter 
> briefly, 
> and was dismayed by how much work would be needed for a real fix, even if I 
> fixed only timefns.c.

Can you point out a couple of such places?  I'm not sure I understand
the nature of the problem.  The data width difference notwithstanding,
the values should all fit in 32-bit time_t.

> Wouldn't it be much better to remove the "#define _USE_32BIT_TIME_T" from 
> nt/inc/mingw_time.h? That is what's causing the problem that your fix 
> attempted 
> to paper over.

I will take a closer look, but I'm not sure we can do anything about
that.  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.

> A lot of code assumes that a struct timespec (and struct 
> timeval's) tv_sec component is of type time_t, and defining _USE_32BIT_TIME_T 
> violates that assumption; furthermore it means that MinGW Emacs stops working 
> in 
> 2038 (and doesn't work even now for timestamps more than 20 years into the 
> future, something that is pretty routine for me and I imagine for other 
> users).
> 
> Whatever backward-compatibility mess that defining _USE_32BIT_TIME_T attempts 
> to 
> work around, really needs to be worked around in a better way.

The only way is to drop support for older Windows systems.  Which we
will have to do before the year 2038 (unless some other solution could
be found, which I very much doubt).