Time resolution in Emacs

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

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

>> There are Gnulib library functions to
>> deal with this sort of thing; it's not a new problem.
> 
> Doesn't that slow down applications?

Not significantly, no. file-attributes already has the file's filesystem 
ID and timestamps so Emacs can easily cache that (it's a small cache 
with only one entry per filesystem). There's no need to traipse through 
the filesystem looking at other files. This is what coreutils does and 
it works well in practice. It's not expensive and not that complicated.

Your suggestion of maintaining a static table for known filesystem types 
is a good one; we could do that to improve common cases. I would like to 
take a look into doing this. If successful, it should improve coreutils 
and other GNU apps even if Emacs makes no changes in this area. In the 
meantime I'll withdraw the proposed changes that would cause Emacs to 
communicate OS timestamp resolution to the user; that sort of thing can 
wait until after I've had that look (assuming I ever find the time :-).


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

For example, if Emacs imports from the network a timestamp with three 
digits after the decimal point, it should convert it to an internal 
timestamp with millisecond resolution. Conversely when sending a textual 
timestamp, Emacs should generate only as many trailing digits as needed. 
This sort of thing is not perfect (nothing to do with timestamps is :-), 
but it is better than losing whatever resolution information is available.