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

[Brooks Harris]

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

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. 
If it were not, the YMDhms values would be incorrect by the Leap 
Seconds. Of course, because it's lazy about when it syncs, FILETIME 
timestamp values between the actual Leap Second and when the system has 
synced are incorrect by one second.

I've experimented with this extensively to be sure I understood it. In 
fact, the POSIX implementations available in the Microsoft c/c++ 
compilers are actually wrappers around the Windows system calls; 
gmtime() calls FileTimeToSystemTime(), for example.

Meantime, local time parameters are kept in the (hated) Registry. These 
are dynamically updated when a Windows Update runs (a dreaded operation 
carefully avoided by people like me because those (damn) Windows Updates 
too often screw up or break something else somewhere).

Now, you could say, and many of us LEAPSECS nuts would agree, "That's 
horrible!". Yes, but the FILETIME value just keeps marching along and 
billions of people and a bazillion applications are none the wiser. For 
the most part it just keeps working. (With the occasional ctrl-alt-del, 
restart, and other stupid work-arounds needed to overcome all the 
operational  complexities and flaws; "... as we ctrl-alt-del our way 
through life..." ). [Oh! Wait, it changed! Now it's ctrl-shift-esc! Who 
asked for that?!?]

Its more complicated for Windows Server versions - there you need to 
coordinate many OS instances and file systems. (And Windows Server is, 
in some important ways, a different animal than the typical Windows PC 
version). I don't have a lot of experience with Windows Server, so I 
can't explain exactly how they accomplish tighter timing, but it 
obviously happens, otherwise those systems wouldn't work at all.

Note the fact that Microsoft updates Leap Seconds at midnight *local 
time* in Azure. This in contrast to the common practice of introducing 
Leap Seconds in local time simultaneous with UTC. They also are not 
smearing.  The (probably special) NTP server clicks the Leap Second and 
a tightly coupled Windows system just follows. Done. The local time 
results are one-second different from the "simultaneous with UTC" common 
practice for some interval, but, who cares? Microsoft? Please.

The approach makes some sense to me, actually. The "simultaneous with 
UTC" common practice creates a terribly complex and scattered matrix of 
Leap Second appearances in local time YMDhms representations. Its hard 
to calculate, and harder to verify. Introducing Leap Seconds at midnight 
local time is much more managble, since each local time behaves the same 
in that respect.

All this brings up a wider point; any Leap Second-to-Gregorian fix must 
be applicable to many systems, not just POSIX and Linux. If broad swaths 
of the markets do it different ways nothing has been accomplished. The 
discussion must keep all systems, including the evil Windows, in mind.

-Brooks