Re: Time resolution in Emacs

[Eli Zaretskii]

> Date: Fri, 22 Apr 2022 14:52:47 -0700
> Cc: manikulin@gmail.com, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> > 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.
> 
> Also quite right. Emacs needs to determine the timestamp for each class 
> of objects as best it can.

The question is: how feasible is that?  See below; my current
conclusion is that it is not feasible in general.

> > What is the plan for other kinds of time objects?  For example, how
> > would we determine the resolution of file times
> 
> We could do what Coreutils does, in commands like 'cp -u' that sample 
> timestamps in each file system to determine resolution. This approach 
> works well enough in practice. There are Gnulib library functions to 
> deal with this sort of thing; it's not a new problem.

Doesn't that slow down applications?  How many time stamps should we
need to sample to determine a good estimation?  The sampling should be
separate for each filesystem, but do we have information about the
file's filesystem in all cases?  What about the cases of different
accuracies for different times (creation, modification, access)?

These questions need to have practical reasonable answers before we
decide this is tractable.

I also question the need for Emacs to do what few other applications
do (GNU Coreutils are an exception rather than the rule here, AFAIK),
given the tremendous complexities this will require from us.  For
example, 'cp' specifically deals with copying many files, but that's
not what Emacs does in most applications where it cares about
comparing file timestamps with some other class of timestamps.  So
where 'cp' can sample file timestamps of the files it is copying,
Emacs will be unable to do so, without costly traversing directories
it has no business of looking at, and for which it may not have access
rights in the first place.

> > as your examples show, that kind of timestamp is the one that needs
> > resolution information much less than the other ones.
> 
> I don't see how the examples show that.

The 'date' example is IMNSHO artificial and not important, except for
people whose special interest is in time APIs.

> > Please don't be obsessed with MS-Windows.
> 
> There's no obsession here on my part. MS-Windows appears to be the only 
> platform where current-time generates such low-resolution timestamps, or 
> generates syncopated timestamps, and that's why discussion has naturally 
> centered on that platform.

That's what I'm saying: don't center the discussion on Windows.  The
problem is much more general and broad, see above and below.

> > examples you gave deal with
> > file timestamps, and you explained that we do risk losing information
> > there.
> 
> Yes, and Emacs currently loses all information about file timestamp 
> resolution, on all platforms.  It would be better for Emacs to report as 
> much of that information as it easily can. This could be done by using 
> the Gnulib library functions suggested above. Reporting this information 
> is better than losing it.

Please point to those function so they could be studied, or describe
what they do here.  I don't see how this could be reasonably solved in
general, even for file timestamps.

And what about other sources of time data?  For example, timestamps
from other systems (like in your NTP example), timestamps that are
reported by Tramp functions, etc.?  How do we reliably estimate the
accuracy of those?

Once again, without a comprehensive plan that is capable of covering
all the sources of time information we routinely deal with in Emacs, I
don't think we should make any significant changes in our time-API
infrastructure nor in the structure of our time representation
objects.

> > 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?
> 
> Yes, most users don't notice timestamps being a little off. And these 
> users surely won't care whether we improve the timestamps to be more 
> accurate. But that doesn't mean that it's a bad idea to improve 
> timestamp quality.

It isn't a bad idea, but if the complexity it introduces into the way
Emacs handles time information is too high and the benefits are too
low, then we shouldn't add such complexities to Emacs, because the
benefits won't justify the costs.

So far I'm not convinced it is feasible to solve these issues in Emacs
without introducing unreasonable complexity, and even that will only
provide a partial solution.  Once we understand which part(s) of this
can be solved and at what cost, we could perhaps come up with
simplified solutions that avoid most of the costs, such as using a
static database of timestamp accuracies for important classes of
timestamps.  But we aren't there yet, and it is so far premature to
discuss these specifics.