[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: Fri, 22 Apr 2022 00:23:01 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0

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

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?

reply via email to

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