On Fri, 2011-12-23 at 11:19 +1300, Jay Daley wrote:
A network time heads-up.
There has been a debate raging for some years on whether or not to change Universal Coordinated Time (UTC) to be the same as International Atomic Time (TAI), which is due for a major vote at the ITU-R in January. Previous votes have seen it defeated but it keeps coming back.
To explain the background: The rotation of the earth is not precisely the same length of time each year and currently a decison is made every six months whether or not to correct UTC to ensure that midday really is when the sun is at its highest point over the Greenwich meridian, by adding a leap second. 24 have been added over the last 40 years and UTC now differs from TAI by 34 seconds. The proposal, if agreed, will drop this correction and so over a long time the connection between time and the rotation of the earth will be lost.
The implication for networks is potentially quite profound. NTP currently supports leap seconds as do GPS satellite time signals and DCF77 radio clocks but if this proposal is agreed that will be turned off. So if you provide time to a system that take a photograph at the same time every day then that will need two time signals, one for TAI and a new one for earth rotation time. Same problem for anything to do with sun rises/falls and tides (though obviously the precision may not be an issue for some years).
If you want to read more then this article covers the arguments quite well, though biased like me against the idea: http://www.bloomberg.com/news/2011-12-22/un-vote-could-allow-mankind-to-cont...
I'm not sure if NZ has a position on this, but I am trying to find out.
I don't know if NZ has an opinion on the matter :-) I have my own opinion, and I've been involved in calendaring standards for a few years now, which is the background that I personally bring to the debate :-) My opinion is: We should move leap seconds into their own timezone. Rationale: Handling of leap seconds programmatically is quite complex. Potentially quite costly. And when you write software to handle them correctly you will probably find your software interacting with some other software which doesn't, such as the standard Java 'Calendar' class. Software which handles timezones will[1] already handle arbitrary shifts from UTC, occurring at arbitrary dates and times. Mechanisms exist for sharing timezone definitions which have evolved over some time. Over so long, in fact that the main person responsible has long threatened to retire (and is also being threatened with an unrelated nuisance lawsuit, but don't get me started on that...), and those procedures are finally being enshrined into a more structured process. Balancing all of this experience and existing code for handling timezones against the obscurity and uneven implementation of leap seconds, I think that the world will have a more consistent, accurate and trustable time service if we remove the awkwardness of leap seconds from the standard and put it into it's own timezone.
From my reading we have a period of 600 years or so while the difference remains relatively static, and after that point the actual timezones used in people's daily lives may also begin to have one-off variations which are occasionally applied.
There are many implementation details, of course, and no doubt there will be some grumpy astronomers for a while, but at the end of it we will all have a more robust system. Those astronomers probably often get grumpy when they see code using modulo 86400 to work out the second in the day anyway. Last year I actually wrote a date/time handling library that took full account of leap seconds. I've since removed all of that cruft from it after following this debate for a few months, and I sleep easier at night as a result :-) Regards, Andrew McMillan. [1] or they have bugs, but those bugs should be easier to understand and resolve than bugs in handling leap seconds in other ways. -- ------------------------------------------------------------------------ andrew (AT) morphoss (DOT) com +64(272)DEBIAN ... I have read the INSTRUCTIONS ... ------------------------------------------------------------------------