[LEAPSECS] Leap seconds ain't broken, but most implementations are broken

[Brooks Harris]

On 2017-01-08 10:15 AM, Martin Burnicki wrote:
> Brooks Harris wrote:
>> On 2017-01-06 11:52 AM, Martin Burnicki wrote:
>>>> - OS kernels with different features (Windows doesn't even know leap
>>>> seconds, AFAIK)
>>>>
>>>>
>> It is often repeated on LEAPSECS that "Windows doesn't even know leap
>> seconds". That's just not true. It knows very well about Leap Seconds in
>> the same way other systems do but it (typical desktop versions) is lazy
>> about when it updates - it doesn't attempt to update for Leap Seconds
>> until the particular system gets round to syncing to some NTP server
>> (defaulting to time.windows.com, but works perfectly well if set to
>> time.nist.gov, for example).
> Many years ago I wrote a DOS TSR which could read the time from Meinberg
> PCI cards (and ISA cards at that time), and adjusted the DOS time if
> there was a significant difference.
>
> So of course the DOS time was also adjusted after the plug-in card had
> stepped its time due to a leap second.
>
> So according to your argumentation even plain old DOS was aware of leap
> seconds, wasn't it?
Yeah, I think so.

Really, none of DOS, Windows, or (pure) POSIX systems "know" about Leap 
Seconds except in so far as the reference counter (Windows FILETIME or 
POSIX time_t, (I can't remember what counter DOS relied on)) has been 
adjusted by the system in response to NTP queries. That adjustment gets 
reflected to YMDhms representation through calls to win::GetSystemTime() 
or POSIX::gmtime(). (Again, long time since I played with DOS, not sure 
the analogous calls)

By the way, DOS was essentially a real-time OS; you could hammer the 
interrupts however you liked. You don't want to do that in a 
multitasking event driven OS.


>
>> In Windows, FILETIME (an unsigned 64-bit value) is directly analogous to
>> POSIX time_t except it has a 1601-01-01 00:00:00 epoch. struct
>> SYSTEMTIME is analogous to POSIX struct tm ("broken down time" or
>> "YMDhms" representation). FileTimeToSystemTime() is analogous to POSIX
>> gmtime();
>>
>> Like time_t, FILETIME is "bumped" when the system syncs to a NTP server.
> Yes because the time adjustment software slews or steps the time.
>
> Which Windows API call can be used to notify Windows that a leap second
> is pending, so the Windows system time can account for it at the right time?
I am unaware of any part of Windows that is "aware" of Leap Seconds. 
There's no register somewhere that holds current TAI-UTC, announce, or 
history, I'm pretty sure, not at user-level access to the OS system 
calls, anyway.

(I'm hesitant to state this with great authority because Windows as a 
whole is just huge, and there are APIs on APIs developed and exposed 
over the years. I keep discovering yet another API that may expose 
deeper and deeper access to stuff. There might be something buried 
somewhere that can do this somehow. And Windows is always evolving, so 
something new might exist. Windows Server is something of a different 
animal than regular Windows PC versions, certainly with respect to its 
file system support, so there might be something different there 
regarding timekeeping, I don't know. I've never seen documentation of 
any such thing, though.)

Combinations of SetSystemTime() and SetSystemTimeAdjustment() can adjust 
the system clock. I've never tried to use them to tightly adjust system 
time. It would probably not be an easy project because monitoring 
accurate cause and effect would be tricky. I've played with 
SetSystemTimeAdjustment(), and it definitely changes things a bit, but 
never explored it carefully. But SetSystemTime() certainly works in the 
context of setting values obtained from NTP.

These functions adjust the "System timer" which is responsible for 
user-level FILETIME values and such. This is not the the primary CPU 
clock, of course, which you'd dearly love to frequency lock to an 
outside time source, but I know of no OS level call to do that. Of 
course you could build a driver in ring-zero to give it a go, which 
would be fun, but not a weekend project. :-) (Recommendation: do not try 
anything with interrupts unless you are fond of blue-screens.)

I have never discovered any references to or documentation of exactly 
how Windows synchronizes with NTP. Its a black box. (Any tips on this 
appreciated). But from everything I've been able to observe and 
experiment with it behaves the same as running an NTP client application 
and using SetSystemTime() from the NTP results. That works fine, but 
I've never tried to critically evaluate just how tightly this can be done.

As you probably know, some aspects of the clock and timer behavior 
depend on the CPU model, BIOS, associated chip sets, and the Windows 
power-management scheme in use by a given installation, of which there 
are many from different Windows versions to support available hardware 
technology on a given system. For example, the minimum (average) sleep 
time available from ::Sleep() can vary from, like from 10 to 14 
Milliseconds and higher on different systems. I've tested and verified 
that. (Recommendation: never use ::Sleep() for anything; you've gotta do 
it the hard way with thread synchronization mechanisms).

Most of my experience regarding tight timekeeping in Windows revolves 
around obtaining media (video and audio) and device control (things like 
VTR (video tape recorder) control) from external sources, displaying 
those locally or over networks, or emitting media and control to 
external devices. None of this is easy. Windows is not a real-time OS; 
you have to repeat that mantra. Everything needs to be buffered.  
Windows provides many OS systems calls, low-level interfaces, and APIs 
for dealing with threading, media, and serial communications. There are 
several "multi-media" clocks and APIs to chose from, including high 
level APIs like DirectShow. Then there are all the third-party media 
systems like Quicktime and Ffmpeg and a bunch of others. Then too there 
is the whole other world of .NET.

Generally speaking these sorts of applications don't require 
high-precision accurate date-and-time. But the new SMPTE focus on a 
*fixed* date-time epoch (1588/PTP) timing scheme is what came to drive 
my interest in this broader discussion.

-Brooks

>
> Martin
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>