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

[Martin Burnicki]

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?

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

Martin