Re: Time resolution in Emacs

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

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

> There's no reason to expect Emacs to be
> able to support such applications on all platforms.

Quite right. Many people don't synchronize their clocks at all, and on 
their systems Emacs can't generate accurate timestamps.

However, that doesn't mean Emacs should be sloppy about timestamps. If 
an OS has two low-level time primitives A and B, and A's resolution is 
100 ms while B's is 1 ms, surely Emacs should prefer B. Using B helps 
apps that can use 1-ms timestamps in a well-synchronized environment, 
and it doesn't hurt apps that don't care about timestamp resolution.


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

Even if one limits one's attention to NTP on non-realtime systems it's 
not hard to get agreement on a LAN to better than 10 ms, counting OS 
jitter. And better-than-10-ms accuracy is growing in popularity, due to 
applications that need good clocks and get them via PTP or other means. 
I regularly use networks that are synchronized better than 10 ms, and I 
wouldn't pooh-pooh the need for this sort of thing in apps that 
coordinate with others.


> We don't _insist_ on providing low-accuracy timestamps, but we should
> definitely be certainly concerned about adding such non-trivial
> complexity to Emacs

It sounds like we have miscommunicated, as this comment seems to 
disagree with your email of a couple of days ago that said "There's no 
problem whatsoever to provide high-resolution time stamps on MS-Windows".

If the question is whether to use a less-accurate method A or 
more-accurate method B to obtain timestamps, where Emacs continues its 
current practice of converting the timestamps to 1-nanosecond resolution 
internally before the user sees the timestamps, then I don't see why 
Emacs should prefer A to B.