Re: Time resolution in Emacs

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 22 Apr 2022 14:26:16 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>, manikulin@gmail.com,
>  Emacs developers <emacs-devel@gnu.org>
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 4/22/22 11:52, Corwin Brust wrote:
> > Since this seems to be in reply to Eli's question about use-cases, can
> > you elaborate on some of the specific use-cases where 1/64th of a
> > second is insufficient?
> 
> When Emacs needs to deal with more than 64 spaced events per second, or 
> with external time sources that deal with more than 64 such events per 
> second, a resolution of 1/64 second is inadequate.
> 
> In my previous message I gave the example of comparing the current time 
> in 1/64-second resolution to file timestamps in (say) 100 ns resolution, 
> where Emacs can compare timestamps incorrectly.
> 
> Another example would be comparing internally-generated timestamps to 
> Internet RFC 3339 or ISO 8601 timestamps retrieved from the outside 
> world. LANs synchronized via NTP can routinely synchronize clocks to 
> less than 10 ms, and processes running on a single node can synchronize 
> even more closely. But if Emacs reports the current time to within only 
> 1/64 s, its timestamps introduce more clock skew than its underlying 
> platforms do, making it harder to build distributed apps with 
> high-quality timestamps.

You will excuse me, but I find these examples artificial when Emacs
Lisp programs are concerned.  There's no reason to expect Emacs to be
able to support such applications on all platforms.  Not to mention
that synchronizing clocks to millisecond accuracy on non-RT systems is
in most cases futile, because the OS doesn't provide reliable timings
to that accuracy anyway.

> Of course most apps don't need high-quality timestamps. However, I don't 
> see why Emacs would insist on generating low-quality timestamps if 
> higher-quality timestamps are readily available.

We don't _insist_ on providing low-accuracy timestamps, but we should
definitely be certainly concerned about adding such non-trivial
complexity to Emacs for the benefit of extremely rare (if any) use
cases.  So far I have yet to see an example of an important use case
that would justify that, let alone a plan for reasonably practical
ways of providing the time resolution figures for each source of time
information (see my other message).