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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 22 Apr 2022 00:23:01 +0700
> Cc: eggert@cs.ucla.edu, bug-gnulib@gnu.org, 54764@debbugs.gnu.org
> From: Max Nikulin <manikulin@gmail.com>
> 
> >> 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.

No, that's not the case here.

> >> 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

It doesn't matter to us, because we do support older versions.

> 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.

There's no problem having high-resolution time stamps in Emacs on all
versions of Windows since Windows 2000, but before we implement
something like that, we should understand the goal and the effects on
Lisp programs.  Which is why I asked Paul questions that need to be
answered before we talk about the implementation.

> > 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.

We use gettimeofdate, because the more modern clock_gettime requires
linking against pthreads in the MinGW64 builds, and we don't want that
additional dependency.  But since clock_gettime produces the same
15.6 msec granularity, we don't lose anything by using a slightly
older interface.

> It seems, only coarse clock is currently available in Emacs on Windows 
> due to usage of current_timespec.

Yes.

> Are there any known problem with 16ms resolution?

Not that I know of, but please wait for the discussion with Paul to
come to its conclusion.