Re: Time resolution in Emacs argument optional ones

[Paul Eggert]

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.

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.