Re: Time resolution in Emacs argument optional ones

[Eli Zaretskii <eliz@gnu.org>]

This discussion was moved from bug#54764, because it sounds like a
general design issue is at stake here, and IMO we should discuss this
before making any changes.

I've removed the bug tracker and the Org and Gnulib lists from the
addressees, because I think this is strictly an Emacs design issue.
We can add them later if needed.  For now, please refrain from adding
them, to make the signal-to-noise ratio as best as possible.

> Date: Thu, 21 Apr 2022 16:56:25 -0700
> Cc: manikulin@gmail.com, emacs-orgmode@gnu.org, 54764@debbugs.gnu.org,
>  bug-gnulib@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
>  > 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.

Sorry, I don't understand what that "for now" means.  We are talking
about the design of how time objects are represented in Emacs, so that
design should cover all the possible uses of such objects, certainly
those uses which we already know about.  And that definitely includes
file timestamps.

So it is NOT a separate matter.  It should be part of the discussion.

>  > 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.

You again are talking about the current implementation, whereas I
would like to discuss the design and our goals.  There's no problem
whatsoever to provide high-resolution time stamps on MS-Windows, if we
decide that this is what we want.  The only reason we didn't do that
until now is that it wasn't deemed important.

>  > 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.

Then it's a subtle bug in our current code that needs to be solved.

> This sort of disagreement is inherent to how timestamp resolution works. 

I'm asking why timestamp resolution, as defined by HZ, at all matters
in Emacs.  Please answer this question before anything else, because
it is IMO central to this discussion.  In addition to the general
cause you think this is important, please provide a list of use cases
where you can show that using this definition of time resolution is
important, and not using that would lead to problems.

An alternative would be to decide on a unified resolution for time
objects in Emacs, independent on what the underlying system does, and
then use that everywhere.  Why not do that?

The next important question is how do we define "timestamp resolution"
so that it covers all the uses, including file timestamps, time values
that come from external systems, etc.  (Granted, the simple
alternative of using a single unified resolution that is fine-grained
enough to cover all the known uses will solve this problem as well,
and AFAIU solve it simply and cleanly.)

I think we should only change our code after we conclude the
discussion of the above-mentioned general issues, and agree on our
goals and how we will implement those goals.

Thanks.