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.
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.
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..
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.
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.
-- don
* The exact time of this event depends on what happens with leap
seconds.