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 _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
