On 23/12/2011, at 7:11 PM, Andrew McMillan wrote:
I don't know if NZ has an opinion on the matter :-)
I meant the NZ Government and what it would say at ITU-R.
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 :-)
I'm not sure what difference leap seconds make to a calendaring system. Does it matter to a calendaring system that some seconds are actually two seconds long? So long as there is a global time representation then calendaring works. UTC provides this. The beauty of the existing management of leap seconds is that it is transparent for most applications. Writing code to handle them where it is not needed is asking for trouble. cheers Jay
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 ... ------------------------------------------------------------------------
-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840