> Date: Thu, 21 Apr 2022 16:56:25 -0700 > Cc: maniku...@gmail.com, emacs-orgm...@gnu.org, 54...@debbugs.gnu.org, > bug-gnulib@gnu.org > From: Paul Eggert <egg...@cs.ucla.edu> > > 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.
These are very fine details of the implementation, which we can get back to later. I would like first to discuss the more general issue of basing the design on such tests, and on the notion of "clock resolution" as expressed by these tests. TBH, what you propose makes no sense to me for now, and for some reason you didn't answer my more general questions about that, but instead preferred to respond only to their secondary aspects. At this point, I object to any changes in this area until we discuss the more general aspects of this design and decide whether we agree with it. Such a discussion should be on emacs-devel, so I move this there; please continue the discussion there. Thanks.
