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

[Brooks Harris]

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
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>