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

M. Warner Losh imp at bsdimp.com
Fri Jul 15 15:33:28 EDT 2005

In message: <20050715192730.2c468da7.obyrne at iol.ie>
            "Chris O'Byrne" <obyrne at iol.ie> writes:
: 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).

Also, keep in mind that time zones are 15 degrees wide, so local noon
and "the real noon" can vary by as much as 1/2 hour (or more in some
extreme cases).  So worrying about a few seconds (or even several tens
of minutes) here or there being out of sync likely won't matter to
most people.  Civil time could continue to track the defined length of
a second, and drift from true midnight by a lot before people would
start to care or notice.  It wouldn't be until you are a minute off
that things like sunset tables would be affected.

: 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!

Well, the varying length of a second is a non-starter, imho.

However, the idea I like most is to preduct the long term drift over
the next 100-500 years.  Then, we schedule the leap seconds NOW for
that period of time.  I don't know what the state of the art here is,
but something better than 0.5 years into the future is clearly needed.
We do them like clockwork during that time.  Sure, there will be times
where UT1-UTC exceeds a second.  But the difference won't become
unbounded.  This will allow equiptment makers to know what the leap
second offset is for any given time.  It would also regularize leap
seconds and stop them from being the random event that they are today.
You'd always have them, you'd know you always have them which makes
situations like what we have now of a 6 year priod w/o leap seconds
not happening not happen.  The crux of this proposal is our ability to
predict N years into the future and our confidence in that ability
today.  I believe that we have the ability to predict within a minute
(meaning we'll never be more than a minute off) how far things will
drift over the next 500 years, but I could be wrong about that.

It was remarked that GPS receivers produce time in UTC.  This is
mostly true.  There are some that produce it in UTC, but until they
know the leap seconds they 'lie' and produce it with a leap count of
'0'.  With a scheme like the above, you could look at the time in a
lookup table and know what the offset will be and therefore be able to
know what the offset is without waiting for the almanac to download.
You might call this a bug, but it sure is a common one :-(.


More information about the time-nuts mailing list