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

[Max Nikulin]

On 21/04/2022 22:58, Eli Zaretskii wrote:
> > Date: Thu, 21 Apr 2022 22:30:21 +0700
> > From: 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?
>
> It is a well-known fact that the system timer tick happens 64 times a
> second on MS-Windows.

You may notice similar coarse scheduler timer on Linux as well. General 
purpose PC nowadays may have higher scheduler frequency, but I saw a 
case when usleep(1) caused 20ms pause while there was no problem to get 
higher precision form system clock.

> > Clock resolution generally has a little common with timers.
>
> I agree, but that's something you should tell/ask Paul, not myself.

It may be deeper, e.g. additional call during initialization or extra 
privileges may be required.

> > 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
>
> That API exists only since Windows 8.

I suspect that it means just that MS does not support anything prior to 
Windows 8 any more. XP is mentioned in connection to this function: 
https://www.lochan.org/2005/keith-cl/useful/win32time.html

Writing about possible intentional hiding of high precision clock I was 
assuming latest windows versions, I believe, even Windows 8 is too old 
for such modern tricks.

> More importantly the Gnulib
> implementation of current_timespec doesn't use it.

Even if it is not used yet, is it intentional design decision or just an 
issue that should be fixed? I am unsure what function 
clock_gettime/timespec_get/gettimeofday is actually used on windows 
platform and how it is implemented.

It seems, only coarse clock is currently available in Emacs on Windows 
due to usage of current_timespec. Are there any known problem with 16ms 
resolution?