Re: Time resolution in Emacs argument optional ones

[Paul Eggert]

On 4/21/22 22:23, Eli Zaretskii wrote:

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

An example of when this matters is that GNU 'ls' needs to know whether a 
file timestamp is in the future because 'ls -l' uses a different textual 
format for future timestamps than it does for recent-past timestamps, as 
a visual cue to the user that the user has a clock skew problem that can 
screw up GNU 'make' and similar programs. For example, if I run the 
shell script:

  touch now
  touch --date=@$(date +%s.%N | sed 's/........$/99999999/') future
  ls -l future now

Here's the output I should see, because 'future' has a timestamp in the 
future:

  -rw-rw-r--. 1 eggert eggert 0 Apr 22  2022 future
  -rw-rw-r--. 1 eggert eggert 0 Apr 22 11:13 now

However, if GNU 'ls' got the time of day with lower resolution than it 
got file timestamps, it would use the wrong textual format for a 
recently-created file's timestamp, because it would compare a lower-res 
time-of-day like 1650651200.73 to a higher-res file timestamp like 
1650651200.734627956 that was generated before the current time. The 
above example would therefore generate the incorrect output:

  -rw-rw-r--. 1 eggert eggert 0 Apr 22 11:13 future
  -rw-rw-r--. 1 eggert eggert 0 Apr 22 11:13 now

When Emacs needs to do something like what GNU 'ls' does, it can have 
the same issue.

Admittedly this is not the most important issue on Emacs's plate. Still, 
Emacs should do a good job and be compatible with other GNU tools.


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

It matters for applications like GNU 'ls' as described above. It also 
matters for applications that want to display a timestamp accurately, 
but without excess information that bogs down performance and implies 
more precision than is actually present. For example, current GNU 'date' 
can use a format '%s.%-N' that outputs the current time without excess 
trailing zeros in the subseconds part. Emacs should be able to do 
something similar.


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


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

We've already done that in Emacs with the (TICKS . HZ) representation.

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. (By "syncopated clock" I mean one that doesn't beat on 1-second 
boundaries.) This would be simpler than adding support for syncopated 
clocks to the Emacs timestamp format, as syncopated clocks are too much 
trouble to document and implement and would complicated too much code 
for too little benefit.

Besides, a precision of only 1/64 second on the time of day is not 
adequate for quite a few applications these days, so this issue of 
low-resolution time-of-day should be fixed on MS-Windows regardless of 
how Emacs represents timestamps internally.


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

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.

This doesn't mean I'm a fan of the current situation with file 
timestamps. It means only that we can address the current-time problem 
in one patchset, and the file timestamp issue in a later patchset. It 
will be better to separate the solutions in this way, than to try to 
solve the problem all at once.

> It should be part of the discussion.

OK.