On Fri, 2011-12-23 at 23:35 +1300, Jay Daley wrote:
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.
Mostly it's a problem with how to do date arithmetic. Some types of date arithmetic are easiest performed on y/m/d/h/m/s whereas other types are easiest performed on the basis of a continuously incrementing count of time since an epoch. It's really good if both types of calculation produce the 'right' result. A system for scheduling meetings in an office isn't likely to care about leap seconds - it probably doesn't even care about seconds! But the same software can be used for storing schedules for machinery and other things where more precise synchronisation is more important.
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.
Yes, I agree, and that's why I think that putting leap seconds into their own timezone is a simple mechanism to provide general access to the information and the adjustment for those applications that need it. It's great that NTP has hacks to handle moving time around while pretending to the client services that leap seconds don't exist, but they *are* hacks. Seconds do pass during that transition, stuff happens that will sometimes want to be recorded with microsecond accuracy, and compared with something else happening elsewhere. Cheers, Andrew. -- ------------------------------------------------------------------------ andrew (AT) morphoss (DOT) com +64(272)DEBIAN Does the turtle move for you? www.kame.net ------------------------------------------------------------------------