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