Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones

[Max Nikulin]

Eli Zaretskii, Wed, 20 Apr 2022 22:30:21
> I see the time samples change in jumps of 15 msec.  Which is expected
> on MS-Windows, given the scheduler time tick,

Why do you expect such value? Clock resolution generally has a little 
common with timers. Does it mean some protection against timing attacks?

I have no experience with windows-specific code, but quick search gives 
GetSystemTimePreciseAsFileTime that should provide timestamps with fine 
granularity
https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getsystemtimepreciseasfiletime

On 21/04/2022 13:44, Eli Zaretskii wrote:
>    gettime_res returned 625000 ns
>    time = 1650522863.038750000
>    time = 1650522863.054375000
>
> Then I think I don't understand the purpose of this measurement, as
> applied to Emacs Lisp.  For example, you say that this is unrelated to
> file timestamps, but don't we use time values for file timestamps?

It might mean that Emacs already have some problems unrelated to the 
suggested patches.

> And for Windows, all this does is measure the "resolution" of the
> Gnulib emulation of timespec functions on MS-Windows, it tells nothing
> about the real resolution of the system time values.
>
> More generally, if the "time resolution" determined by this procedure
> is different between two systems, does it mean that two time values
> that are 'equal' on one of them could be NOT 'equal' on another?  And
> if so, wouldn't that mean Emacs Lisp programs will be inherently not
> portable?
>
> IOW, how do you intend to incorporate this "time resolution" into
> Emacs Lisp, and what will be affected by that value?

If I got the idea of the patches correctly, it should be a different low 
level representation for the same numbers. However I do not like too 
coarse clock resolution reported by the current implementation.

P.S. I have removed emacs-orgmode list since this part of discussion is 
unrelated to Org.