[time-nuts] Re: UTC - A Cautionary Tale
obyrne at iol.ie
Tue Jul 19 05:56:13 EDT 2005
Those of you on the LEAPSECS mailing list will aready have seen this,
but I think its worth a read -
I'm responding to Rob and Mike in this email.
First, Rob said
> And if your software reports eclipses later than 2007, it may need to
> be updated again. Where is the surprise in this? You have built a
> program that makes certain assumptions about time - those assumptions
> are invalid. Your program could have been layered on TAI. Your
> program could have referenced one of the online sources of leap
> second tables (ftp://maia.usno.navy.mil/ser7/tai-utc.dat). Your
> program could have permitted input of an explicit leap second
> schedule at a later date. Your program could have done a lot of
> things to be responsive to the standard. If a standard exists and
> you ignore the standard, you can't blame the folks who designed the
> standard for your problems. For example, what does your program do
> to correct for DUT1? DUT1 will be growing without bound if the
> proposal is adopted. It will become a larger and larger effect to
> compensate for.
> Leap seconds exist now. UTC uses them now. You chose to ignore an
> international standard that applies now. I'm glad to see you were
> perceptive enough to manually correct the problem, but it sure looks
> like it's your problem to me, *no matter what* you think of leap
First of all, there is no surprise. Second of all, my program could not
be layered on TAI - why? Because TAI is not available to the average
user! The average user only has access to UTC, and so that is what I had
to use. (Internally, I use TDT, but I need to know the number of leap
seconds to convert TDT to UTC). Third, I could not access online sources
of information - many mobile phones don't have the infrastructural
capability to access and parse on-line sources of information. Forth, of
course DUT1 is also a problem for me, but it is a problem that is
significantly less important than leap seconds. A 0.9 second error in
DUT1 corresponds to a 0.1 second error in the observed time of an
eclipse on the equator (the worst-case scenario). Finally, of course I
could have implemented something whereby the users of the program had to
manually insert the number of leap seconds, but I SHOULDN'T HAVE TO!
As a general citizen of the world, I am APPAULED that astronomers can
tell when an astronomical event years from now will occur to within a
fraction of a second, but they cannot tell me what time will be on my
watch at that time!
> There is interval time and there is time-of-day. There are a number
> of other timescales as well. What is difficult to forecast is the
> relationship between TAI and UT1.
And, between TAI and the time that is on my watch. This is, IMO, insane!
> Jean Meeus's discussion:
> (I'm sure anybody with your avocation is familiar with Meeus.)
I am indeed very familiar with Meeus. However, Meeus seems to have set
his sights a bit low. If I'm reading him correctly, Meeus wants to
publish his predictions in UT, saying that its close enough to UTC and
hence the time people keep on their watches. However, no-one can predict
UT into the far future. If, on the other hand, civil time were to be
based on a quadratic equation in TAI, it could be predicted far into the
future, and hence Meeus and others would be able to publish PRECISE
lists of astronomical events far into the future safe in the knowledge
that if there are no changes to the quadratic equation, their
predictions would show PRECISE clock time for those events.
> On the other hand, what you are saying doesn't remove the need for
> lookup tables. Either the lookup tables are needed to move from a
> civil time based on UT1 to TAI or they will be needed to move from a
> civil time based on TAI to UT1.
There is no solution that can simultaneously eliminate lookup tables AND
involve UT1. My solution isn't interested in UT1 - it is interested in
an approximation of UT1 that is accurate over the long term (hundreds
of years, maybe thousands), though may drift (possibly horribly) over
the short term. The vast majority of people are not that worried about
drifts that would (apparently) horrify the subscribers to this list!
> My fundamental assertion is that at
> the end of the day it will be proven that most usages of civil time
> depend on its nature approximating time-of-day rather than
> unsegmented interval time.
Agreed! But my approach achieves both! (At least, to within many parts
per million - which is far more accuracy than most people are interested
> > So I may have to update my eclipse-predicting program within a
> > month of
> > the eclipse? I don't think so.
> But that is the international standard already in effect.
> stops the IERS from issuing a leap second the month before any
> eclipse you care to reference. We should emphasize this by making it
> the rule, not the exception.
I strongly disagree. As I said, I'm appauled that I have to depend on
some bureaucratic scientists in France before I can issue useful,
accurate eclipse predictions. (By "useful", I mean predictions that are
based on the time people have on their wristwatches).
> And we and other interested parties
> should spend our time developing systems that provide the APIs and
> services you need to embed in your application.
I can see where you are going with this. Unfortunately, I cannot see
such APIs working on mobile phones, or on electromechanical clocks for
> By attempting to ignore an intrinsic reality, we are making such
> issues more likely, not less. How about an extension to ISO 8601
> that would permit distinguishing timescales, something like:
> 2005-07-18T12:34:56Z (UTC)
> 2005-07-18T12:35:28A (TAI - same instant)
I would be very much in favour of that if TAI were made as easily
available to the general public as UTC. Unfortunately, most broadcast
time services are set up to broadcast just one timescale, and pretty
much all clocks display just one timescale, and that timescale is UTC,
and is unlikely to change!
> Multiple timescales will always exist. We should acknowledge that
> fact and move on.
> > leap hours are 3,600 times more absurd!
> Common ground has been reached.
> Please be consistent. You said:
> Which means either the interval calculation is based on TAI, and is
> exact, or it is an estimate based on solving quadratic equations.
> Since you very specifically referred to it as an estimate, it must be
> the latter.
OK - let's go through this step-by-step (and apologies to the rest of
The problem is to determine the time interval, in SI seconds, between
two instances in time (a very common problem). And we are comparing the
results of doing that calculation using two different timescales.
The rules are those of "simple arithmetic". You are not allowed to use
lookup tables, and you are not allowed to use quadratic equations. You
are in a hotel, without access to your normal sources of reference,
without access to a calculator, sitting down with someone, doing a
calculation on the back of an envelope.
The first timescale is UTC. A UTC second is of the same duration as an
SI second, but it has leap seconds. The time interval you are required
to calculate is from 2005 Dec 31 23:59:59.9 and 2006 Jan 01 00:00:00.1.
Under the rules, you come up with an answer of 0.2 seconds. The actual
answer is 1.2 seconds. You are out by a factor of 6.
The second timescale is one that is tied to TAI by a quadratic equation.
It has no leap seconds, but the duration of its second varies in
relation to the SI second. At present, its second differs from the SI
second by about one part in 30 million. The time interval you are
required to calculate is a different one from the one above, even though
it looks the same - namely from 2005 Dec 31 23:59:59.9 and 2006 Jan 01
00:00:00.1. Why is it actually a different time interval? Because it is
in a different timescale. The answer you come up with is 0.2 seconds.
You are out by about 1 part in 30 million. You have an answer that is 8
orders of magnitude better than the UTC one.
Of course, this example brings out the worst in UTC - most calculations
involving time periods of less than a year will generate the precisely
correct answer in UTC, and an answer that is always wrong by 1 part in
many millions in the other timescale. My point is that most people are
not interested in precision of 1 part in many millions (see the article
linked-to above), and the benefit of not having to use lookup tables is,
I think, worth the cost of one part in many millions precision.
> >And, from the point of view of programming, quadratic equations are
> >much easier to implement than look-up tables.
> That depends entirely on the platform. That would not be the case on a
> microcontroller lacking hardware floating point.
Not true - floating point can be implemented in software. Also, to the
precision of the numbers you are using, it is not that difficult to do
quadratic equations using integer arithmetic.
> > Not if you have mislaid the piece of paper that has the damn lookup
> > table on it.
> Myself, I would store such information in electronic form so it was
> directly accessible to the program, but suit yourself.
Myself, I like not to depend on electronic equipment that needs
power/batteries/costs lots of money/can get stolen/can get mislaid.
> >Yes. Leap seconds are absurd enough, leap hours are 3,600 times more
> You forgot to extrapolate that statement to leap days.
Leap days are extrapolatable for the next 1,000 years at least. There
are very simple, precise, integer arithmetic algorithms for dealing with
leap days. There are no such algorithms, and cannot be any such
algorithms, for leap seconds.
More information about the time-nuts