Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones

[Paul Eggert]

What appears to be happening here is that the MS-Windows native 
timestamp resolution is 1/64th of a second, and your system's clock is 
offset by 0.0075 s from an integer boundary. I.e., the timestamps in 
increasing order are:

  ...
  1650522862 + 62/64 + 0.0075 = 1650522862.976250
  1650522862 + 63/64 + 0.0075 = 1650522862.991875
  1650522863 +  0/64 + 0.0075 = 1650522863.007500
  1650522863 +  1/64 + 0.0075 = 1650522863.023125
  1650522863 +  2/64 + 0.0075 = 1650522863.038750
  ...

and the system clock never returns a timestamp on an integer boundary 
(i.e., tv_nsec is never zero).

We have two options to express this as Emacs timestamps:

(1) We can keep information about resolution but lose information about 
time, by using a resolution of 15.625 ms (i.e., 1/64 s) and truncating 
timestamps to the nearest 1/64 second.  This would generate the 
following (TICKS . HZ) timestamps:

  ...
  (105633463230 . 64) = 1650522862 + 62/64 = 1650522862.968750
  (105633463231 . 64) = 1650522862 + 63/64 = 1650522862.984375
  (105633463232 . 64) = 1650522863 +  0/64 = 1650522863.000000
  (105633463233 . 64) = 1650522863 +  1/64 = 1650522863.015625
  (105633463234 . 64) = 1650522863 +  2/64 = 1650522863.031250
  ...

(2) We can keep information about time but lose information about the 
resolution, by using a resolution of 0.625 ms (i.e., HZ = 1000000000 / 
625000 = 16000). (We use 0.625 ms because it is the coarsest resolution 
that does not lose time info.) This would generate the following (TICKS 
. HZ) timestamps:

  ...
  (2640836580762 . 1600) = 1650522862 + 1562/1600 = 1650522862.976250
  (2640836580762 . 1600) = 1650522862 + 1587/1600 = 1650522862.991875
  (2640836580762 . 1600) = 1650522863 +   12/1600 = 1650522863.007500
  (2640836580762 . 1600) = 1650522863 +   37/1600 = 1650522863.023125
  (2640836580762 . 1600) = 1650522863 +   62/1600 = 1650522863.038750
  ...

The patch does (2), and this explains the "gettime_res returned 625000 
ns" in your output.

It shouldn't be hard to change the patch to do (1), if desired. I doubt 
whether users will care one way or the other.


> don't we use time values for file timestamps?

Yes, but file timestamps should use the resolution of the file system, 
which in general is different from the resolution of the system clock. 
That's a separate matter, which would be the subject of a separate 
patch. For now we can stick with what we already have in that department.


> And for Windows, all this does is measure the "resolution" of the
> Gnulib emulation of timespec functions on MS-Windows, it tells nothing
> about the real resolution of the system time values.

If Emacs Lisp code (which currently is based on the Gnulib code) can see 
only (say) 1-microsecond timestamps, then it doesn't matter that the 
underlying system clock has (say) 1-nanosecond precision. Of course it 
would be better for Emacs to see the system timestamp resolution, and if 
we can get the time of day on MS-Windows to a precision better than 1/64 
second then I assume Emacs should do that. Once it does, the patch 
should calculate a higher HZ value to tell users about the improved 
resolution.


> if the "time resolution" determined by this procedure
> is different between two systems, does it mean that two time values
> that are 'equal' on one of them could be NOT 'equal' on another?

Sure, but the traditional (HIGH LOW MICROSEC PICOSEC) representation has 
the same issue. For example, if A's clock has 1 ms resolution and B's 
clock has 10 ms resolution, A's (time-convert nil 'list) called twice 
would return (say) the two timestamps (25184 64239 1000 0) and (25184 
64239 1001 0) at the same moments that B's calls would return (25184 
64239 1000 0) twice. A would say that the two timestamps differ; B would 
say they're the same.

This sort of disagreement is inherent to how timestamp resolution works. 
It doesn't matter whether the timestamps are represented by (HIGH LOW 
MICROSEC PICOSEC) or by (TICKS . HZ); users will run into the same 
problem in both cases.