[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Max Nikulin
Subject: Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones
Date: Thu, 21 Apr 2022 22:30:21 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0

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

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]