On 2017-01-06 05:33 PM, Zefram wrote:
Brooks Harris wrote:
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
No, what it does doesn't involve knowing about leap seconds. It's not
just applying the leap second late; it doesn't understand that a leap
second is pending.
Sure. Neither does POSIX. Some Linux implementations may, but these are
extensions of POSIX.
Rather, it merely discovers, upon the next NTP query,
that its clock is wrong by a second. It steps the clock to correct
the discrepancy, but even then has no understanding of how the error
came about. If it does not consult an NTP server, then it will never
correct for the leap second.
Right.
Knowledge of the leap second would imply, at minimum, that the system
will eventually apply the leap second to its clock without any need to
consult an external source.
That would indeed be a smart computer. If it can divine the next Leap
Second without need to consult an external source, maybe it could also
predict future stock values? :-)
Putting aside this foolish notion of "lazy
update",
I guess you don't like that phrase. There are other irritating things in
Windows called "lazy", like "lazy flush"; the way it postpones
completion of flushing file buffers and closing files until the OS gets
around to it. You have to be careful of that one when messing with
near-real-time media handing.
one would expect a system with knowledge of the leap second to
show the correct time immediately after the leap.
We'd all like that, but it doesn't happen on a regular Windows desktop PC.
Much discussion on LEAPSECS concerns variants of Linux and Leap Second
handling "in the kernel". Here you're trying to drive the system to be
as close as possible to its NTP time source. That's good. And it can be
close, but its not a real-time OS either.
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.
Also unable to represent the leap second itself.
Right.
Note the fact that Microsoft updates Leap Seconds at midnight *local time* in
Azure.
Wasn't it established that the report of that behaviour was mistaken?
I didn't see that it was mistaken or refuted. I'd asked earlier if
anyone could confirm it. Did anyone learn more?
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.
Whereas applying a leap second at local midnight breaks the simple hour
offsets between zones.
Well, yes and no depending on how you look at it and calculate it. More
on this later...
All this brings up a wider point; any Leap Second-to-Gregorian fix
Misplaced use of "Gregorian" here. I think you want "TAI" there.
I meant dealing with the mismatch between UTC with Leap seconds and
86400-second-day systems, which (pure) Gregorian and POSIX, are.
applicable to many systems, not just POSIX and Linux.
Conveniently, library code to handle UTC<->TAI conversions and related
computations will tend to run happily even in the benighted lands
of Windows.
Right. Windows isn't really any different than any other OS in this
respect. They all descend from computer development heritage in general,
and they're all fundamentally 86400-second-day systems.
-Brooks
-zefram
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
