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
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.
* The exact time of this event depends on what happens with leap seconds.
NZNOG mailing list
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840