On 23/12/2011, at 6:45 PM, Don Stokes wrote:
On 23/12/11 11:19, Jay Daley wrote: [stuff about aligning UTC with TAI]
One thing folks should be aware of is that the "UTC" on your computer is not UTC at all. Oh, the current time might be correct, but the way leap seconds are implemented is simply to adjust the clock by a second, not to adjust the representation of the time. Thus, you find that the time stored in your computer is the number of seconds since midnight, 1 January 1970, as if there were no leap seconds inserted.
Zero time on Unix and Unix-derived systems is actually 1 Jan 1970 00:00:24 UTC.
I'm not sure what point you are making here. If you ask a Unix computer conditioned by NTP what the time is it answers with the correct time in UTC. If you ask it how many seconds has elapsed since a particular point then that might not be correct as it does not include leap seconds. But the two uses are very different. If you are doing something that requires second/sub-second precision then either account for leap seconds or use a time source that doesn't use them. Leap second files are readily available and can be transmitted by NTP.
The Unix time APIs allow for leap seconds, e.g. this extract from a Linux asctime() man page: tm_sec The number of seconds after the minute, normally in the range 0 to 59, but can be up to 60 to allow for leap seconds. but this element of the API has never been implemented. Introducing leap seconds to Unix time in a way that would make this API element correct would actually break stuff, because, for example, time modulo 60 gives seconds past the minute boundary, and introducing leap seconds into the system time would break anything that assumed this was true. It would also create problems when time from a system implementing leap seconds is presented to one that that isn't.
The reality is that insertion of a positive leap second involves back-stepping, stopping or slewing the clock. That means for the duration of the adjustment, at least one "second" is not actually a second long. It's a small thing for most protocols (most of us have learned to live with time discontinuities, as they happen due to loss and/or subsequent regain of time synchronisation a lot more often than due to leap seconds ... has anybody else fixed ntpd, and suddenly had their screen-saver kick in?), but the fact remains that leap second are handled in a way that can only be described as introducing an error.
NTP is constantly correcting the clock. Leap seconds are treated like any other large correction. Admittedly this does take a while but as explained above this is only a problem if second/sub-second resolution is needed.
On average, a leap second is added every two years -- it varies, there have only been two since 2000, vs one or even two a year through the '70s. At a rate of one every two years, it'll be over three thousand years before the time offset from celestial time reaches half an hour, at which point folks might start to notice. That's rather longer any widely used modern calendar has been codified to any level of accuracy..
The proposal requires a leap hour to be added after 600 years.
My personal view: Stop doing leap seconds for time co-ordination. Publish tables of UTC to celestial time offsets, with suitable libraries and APIs. Make it more accurate than applying leap seconds, so it' s really useful to those who actually care about astronomical position, and can be safely ignored by those who don't. Stop messing with the actual ticker, and live with the 34 second offset to TAI.
We already have a time system that compensates for leap seconds, so why remove that and then invent a replacement that does the same thing?
Just to put this into perspective, at about a quarter past three* in the morning of Tuesday, 19 Jan 2038, 32 bit signed Unix time will roll over. That's in just over 26 years. New industry hires will have to deal with this during their careers. And it's not just a matter of "upgrading" to 64 bit time; you have top deal with 32 bit fields in file systems and various other data storage formats. It'll be Y2K all over again, except harder to explain to the masses.
Which is the perfect opportunity to implement a new time system that provides all the correctness needed for computers while leaving UTC via NTP alone. cheers Jay
-- don
* The exact time of this event depends on what happens with leap seconds. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840