[time-nuts] Re: UTC - A Cautionary Tale

Chris O'Byrne obyrne at iol.ie
Fri Jul 15 14:27:30 EDT 2005

Surely the way to look at the timescales and leap second issues are to
look at the requirements and go from there.

It seems to me that there are two basic requirements. Scientists of
various colours need a regular timescale, and are not particularly
concerned if the sun is above or below the horizon at 12:00:00.000 in
Greenwich. TAI fulfills the job perfectly.

The rest of us need a useable timescale where the sun is basically due
south in Greenwich at 12:00:00.000. However, since the equation of time
introduces a natural error of +/- 15 minutes or so in the exact time at
which the sun is due south in Greenwich, a few more minutes of error in
civil time vs UT really won't affect anyone greatly. TAI will also do
the job here, but only in the "short" term (maybe 200 years).

Those of us who are responsible for providing civil time (eg computer
programmers) also have needs - the timescale needs to be predictable.
It must be tied to TAI somehow.

Astronomers also have needs, of course, but the needs of astronomers
simply cannot be fulfilled without the use of lookup tables, no matter
how you cut it. And, astronomers are clever people who will undoubtedly
find a way with working with whatever timescale they have to hand.

So here is my suggestion, and it is an amalgamation of ideas from
various quarters. Civil time should be based on a quadratic formula
involving TAI. In other words, civil time should track UT over the long
term, and be allowed to drift against UT over the short term. I imagine
that it should be possible to keep the difference between civil time and
UT to well within a few minutes for many centuries into the future, and
that potential error of a few minutes really won't affect anyone that
badly. Also, with the power of modern computers, it should be no problem
to convert TAI into Civil Time - I'm sure someone will even be able to
come up with a simple integer arithmetic formula for doing it. Such a
timescale would have a varying, but entirely predictable, duration of a
second. And it would have NO leap seconds!

I'm guessing that someone has thought of that before, and that the idea
was shot down...???


More information about the time-nuts mailing list