emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: bug-gnulib@gnu.org, manikulin@gmail.com, emacs-orgmode@gnu.org,
	54764@debbugs.gnu.org
Subject: Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones
Date: Thu, 21 Apr 2022 16:56:25 -0700	[thread overview]
Message-ID: <aa2bc0a0-1bec-37ff-919d-c20fcdfdab68@cs.ucla.edu> (raw)
In-Reply-To: <83y1zzq6kd.fsf@gnu.org>

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.



  reply	other threads:[~2022-04-21 23:57 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-07 12:37 Max Nikulin
2022-04-09  7:52 ` Paul Eggert
2022-04-10  3:57   ` Max Nikulin
2022-04-13 14:40   ` Max Nikulin
2022-04-13 18:35     ` Paul Eggert
2022-04-14 13:19       ` Max Nikulin
2022-04-14 22:46         ` Paul Eggert
2022-04-15  2:14           ` Tim Cross
2022-04-15 17:23           ` Max Nikulin
2022-04-16 19:23             ` Paul Eggert
2022-04-21 16:59               ` Max Nikulin
2022-04-19  2:02             ` Paul Eggert
2022-04-19  5:50               ` Eli Zaretskii
2022-04-19 22:22                 ` Paul Eggert
2022-04-20  7:23                   ` Eli Zaretskii
2022-04-20 18:19                     ` Paul Eggert
2022-04-20 18:41                       ` Eli Zaretskii
2022-04-20 19:01                         ` Paul Eggert
2022-04-20 19:14                           ` Eli Zaretskii
2022-04-20 19:23                             ` Paul Eggert
2022-04-20 19:30                               ` Eli Zaretskii
2022-04-21  0:11                                 ` Paul Eggert
2022-04-21  6:44                                   ` Eli Zaretskii
2022-04-21 23:56                                     ` Paul Eggert [this message]
2022-04-22  5:01                                       ` Eli Zaretskii
2022-04-23 14:35                       ` Bernhard Voelker
2022-04-20 15:07               ` Max Nikulin
2022-04-20 18:29                 ` Paul Eggert
2022-04-25 15:30                   ` Max Nikulin
2022-04-25 15:37                     ` Paul Eggert
2022-04-25 19:49                       ` Paul Eggert
2022-04-30 11:22                         ` Max Nikulin
2022-05-01  2:32                           ` Paul Eggert
2022-05-01 17:15                             ` Max Nikulin
2022-04-13 15:12   ` Max Nikulin
2022-04-16 16:26   ` Max Nikulin
2022-04-17  1:58     ` Paul Eggert
2022-04-20 16:56       ` Max Nikulin
2022-04-20 19:17         ` Paul Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aa2bc0a0-1bec-37ff-919d-c20fcdfdab68@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=54764@debbugs.gnu.org \
    --cc=bug-gnulib@gnu.org \
    --cc=eliz@gnu.org \
    --cc=emacs-orgmode@gnu.org \
    --cc=manikulin@gmail.com \
    --subject='Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).