Re: Time resolution in Emacs

[Eli Zaretskii]

> Date: Mon, 25 Apr 2022 08:34:04 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: manikulin@gmail.com, emacs-devel@gnu.org
> 
> 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.

Sorry, I don't understand.  Suppose the given Emacs session called
file-attributes on only 1 file: how do we know the resolution of the
file timestamps from that single file?  The fact that a timestamp has
N last digits zero says nothing at all about the resolution.

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

Thanks, I think for starters we don't need anything else, like dynamic
determination of the actual resolution.

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

Yes, it can definitely wait.  I'd like first to see if my proposal is
good enough, and if not, to hear really good reasons why not.

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

I'm not sure this is TRT.  What do you do if you get a timestamp whose
fractional part looks like .123000 -- do you consider this to be
millisecond resolution or microsecond resolution?  If the latter, we'd
get in trouble as result of trivial arithmetics on timestamps; if the
former, you risk losing resolution for now good reason, just because
the time stamp was too "round".

> Conversely when sending a textual timestamp, Emacs should generate
> only as many trailing digits as needed.

It's very hard to keep only that many significant digits when working
with fractional numbers.