Re: Time resolution in Emacs argument optional ones

[Paul Eggert <eggert@cs.ucla.edu>]

On 4/22/22 12:35, Eli Zaretskii wrote:

> to do such comparisons correctly we need to
> have each time object state its resolution, otherwise you will never
> know how to compare them.

Yes, quite true.


> 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 current implementation of measuring that resolution
> fails miserably on MS-Windows, producing a very incorrect value.)

It's a correct value for what it's measuring, which is (roughly) the 
number of digits needed to express each timestamp precisely. It's not 
correct for a different measure, namely the timestamp resolution, which 
it sounds like is what you'd prefer. As I mentioned in 
<https://bugs.gnu.org/54764#111> it shouldn't be hard to support this 
other measure, and I can look into doing that.


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


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


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


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


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