Re: Time resolution in Emacs argument optional ones

[Eli Zaretskii]

> Date: Fri, 22 Apr 2022 11:22:11 -0700
> Cc: manikulin@gmail.com, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> > 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.
> 
> Doing what GNU 'ls' does, and what GNU 'date' does, are two use cases. 
> Another example is doing what GNU 'cp -u' does when comparing file 
> timestamps. I expect there are others.

It is ironic that you wanted to leave file timestamps alone, but
almost all of the examples you show are related to comparing file
timestamps with other timestamps.

I think there's no problem whatsoever in what we do as long as we
compare times whose source is the same, i.e. has the same resolution.
For example, even with the 15.6 msec resolution of the system time
functions on MS-Windows, we have no problems with stuff like timers in
Emacs -- we just lose the capability of reliably running timers with
time intervals smaller then the resolution.  But we never err about
which system time is later.

It is only when comparing timestamps from different sources that the
problem might appear.  But to do such comparisons correctly we need to
have each time object state its resolution, otherwise you will never
know how to compare them.  We cannot simplify by assuming that one of
them is more accurate and use the resolution of the less accurate one,
because such assumptions will never hold.  For example, while it's
true that file timestamps are more accurate on MS-Windows than the
system clock, sometimes it's the other way around: when using FAT32
volumes, the file time resolution is 2 sec (and, btw, that affects
GNU/Linux systems as well, when they use such filesystems).  Moreover,
some filesystems have different time resolution for different times
(creation, modification, access) on the same type of volume.

So, then, to do this stuff correctly, we need to assign resolution to
each time object.  That resolution cannot be possibly determined by
measuring the system clock resolution, because doing that will at best
provide the figure for one class of time objects.  ("At best" because,
as we saw, the current implementation of measuring that resolution
fails miserably on MS-Windows, producing a very incorrect value.)
What is the plan for other kinds of time objects?  For example, how
would we determine the resolution of file times -- do we have the
technology of telling that for each time field on each type of
filesystem we want to support?  And what about other types of time
objects, for example, those that come via Tramp from remote hosts --
how do we measure or otherwise tell their resolution?

Without having some plan to obtain reliable resolution figures in all
these and other important use cases, it makes no sense to me to
introduce resolution for just one kind of timestamp, especially since,
as your examples show, that kind of timestamp is the one that needs
resolution information much less than the other ones.

> The obvious fix here would be to use better time-of-day primitives on 
> Microsoft Windows, in particular, primitives that don't use a syncopated 
> clock.

Please don't be obsessed with MS-Windows.  The issue is much more
general and acute, as I tried to explain above.  What is the plan for
resolving the more general issue given the state of our knowledge and
technology, and the variety of sources of time data, each one with its
own resolution?  Is this at all feasible enough to even try?  It makes
no sense to me to start if we cannot solve this at least in most
cases.

> I meant that we can stick with what we currently do for file timestamps, 
> which is to generate Emacs Lisp timestamps with a greater resolution 
> than what the file timestamps actually have. This loses information 
> about the resolution, but does not lose information about the time values.

I don't understand this.  Two out of 3 examples you gave deal with
file timestamps, and you explained that we do risk losing information
there.  Given this importance of file timestamps, without having some
plan of solving that problem, the rest is actually a moot point,
because even if we consider the (contrived) example with 'date'
important for some reason, the result will be incorrect there for a
couple of milliseconds, and thereafter will become correct, and who's
to know, or care, that it was incorrect for those 2 milliseconds?

IOW, as long as we are talking about timestamps from the same source,
in this case from the system clock, the problem is so infinitesimally
small that it's almost academic, not a practical one.  So it makes
little sense to me to make changes just for that one class of
timestamps without a clear plan for the other classes.