[LEAPSECS] Google, Amazon, now Microsoft

Brooks Harris brooks at edlmax.com
Sat May 30 22:02:58 EDT 2015


Hi Tom and Rob,

On 2015-05-30 06:05 PM, Tom Van Baak wrote:
>> Perhaps one should point out that local midnight is pretty much the worst
>> possible time for astronomers to accommodate such a change?
> Hi Rob,
>
> Oh, you're such an old earth+photon guy. Ask any space probe, neutrino, or gravitational astronomer if they share your sleep problem. ;-)
>
> I understand that's why JD rolls over at noon instead of midnight. But, for the other 7 billion people on the planet, it's nice that the calendar, and local legal time, and even MJD rolls over at midnight instead of noon.
>
> I can totally sympathize with Microsoft's "fix" for leap seconds.
I can't find any authoritative announcement or statement to this effect 
from Microsoft, and most references seem to go back round to this "The 
Register" article. Where does this information come from?
> Laugh if you want. But out of history, ignorance, compatibility, or dogma their first fix was never to accept or display a 61st second in the first place. Windows is more POSIX than POSIX, when you think about it.
Well, the lack of the 61st second (and 58 rollover) in most computer 
timescale implementations is at the root of the Leap Seconds problems. 
Windows shares that flaw - the Leap Second count itself goes missing.
> This recent "fix"
I got to thinking - what does Windows itself do, what has it always 
done, in this respect? Its sort of an obvious question that never 
occurred to me. I think maybe it's always done what this article says 
Azure its now going to do (or has been doing all along?).

I was experimenting a bit with the Windows time API itself to see if I 
could determine this. My investigation is a bit inconclusive at the 
moment, but I can't see where there is any difference in the way it 
counts on local timescales, in other words all local timescales are 
identical including, it seems, that a Leap Second occurs just before 
midnight. I'm not sure yet.

Finding authoritative information about Windows time mechanisms is 
difficult. I've never found a detailed enough explanation to answer my 
questions satisfactorily. Parts are obvious enough - it follows NTP, and 
it has dynamic (with a Windows update) timezone information in its 
registry (which conveniently does not match tz database). I don't 
believe it retains the Leap Second history anywhere.

There is this recent article that shows just how complicated the 
questions actually are.. Oh, and note, Window has had a "smear" 
mechanism in it since at least 2000 Server. Its not clear from this if 
that smear would, or is intended to, "paper over" a Leap Second from NTP.

How the Windows Time Service Works
https://technet.microsoft.com/en-us/library/cc773013(v=ws.10).aspx

Also note -
GetSystemTimeAdjustment function
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724394

SetSystemTimeAdjustment function
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724943

> avoids another side effect of leap seconds -- where it affects the Far East much more than Europe or even the US. Now every timezone gets the same treatment as London.
Its much more symmetrical and easier to implement that way.
> Yes, I know it's "against UTC rules".
Can anyone point me to a standard or specification that *explicitly and 
clearly* states that a Leap Second is to be accounted for, or 
instantiated, in the local-time count at any other time-point than the 
last second of the day? I've seen it stated, but not as an official, 
international, agreement or specification. It seems to be only "common 
use", and if Windows isn't doing it then its not very common.

In glibc we see that __tzfile_compute() (amongst the many functions 
related to gmtime() ) executes rather complex code that appears to apply 
the Leap Second differently on different timezones.

I'm quite familiar with the details and source of the implementation of 
the POSIX time mechanisms as supplied by the Microsoft MSVC c/c++ 
environment. It doesn't have mechanisms to treat the Leap Second 
differently on different timezone like glibc seems to.

I've studied the POSIX spec in regard to time carefully. I don't see 
where it calls for treating different timezone Leap Second updates 
differently. Maybe I'm missing it? How is it that glibc seems to have 
taken up that convention? Why does Microsoft's implementation lack it? 
Can anyone explain this?

>
> I'm also looking forward to reading the unpublished research papers that discuss the negative side of having 24+ different leap second events around the globe. What a mess.
Yes, it really doesn't make sense to have a discontinuity in the count 
in the middle of the day. Of course the whole of timekeeping barely 
makes sense. :-)

-Brooks
> On a positive note, this means one could actually experience more than one Windows non-leap-second on June 30. Maybe this year I should try to celebrate the leap second twice, in Mountain and in Pacific time. Time to pull out the road map.
>
> /tvb
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>



More information about the LEAPSECS mailing list