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

Chris O'Byrne obyrne at iol.ie
Mon Jul 18 08:34:52 EDT 2005


Bill asked -

> The initial message asserts that leap
> seconds are harmful. The argument remains unfocused because the
> nature of the harm has not been specified.

I'll give you a very concrete example of the harm of leap seconds. As
part of my interest in astronomy, I chase total solar eclipses. I've
written a program that runs on your mobile phone to calculate when you
can expect to see the eclipse start and end from your location
(http://www.ecliptomaniacs.com/resources/j2me/) to a target accuracy of
0.1 second. I updated the program, and made an announcement of its
availability, HOURS before the recent bulletin from the IERS about the
December 2005 leap second. Since the next major eclipse is in 2006, I
had to update the software and make yet another announcement about it.

An unforecastable civil timescale is just not workable, IMO. Also, a
civil timescale that breaks the ancient equality of one minute equals
sixty seconds is wrong, IMO. As I asked recently, what should analogue
clocks do this December?

Finally, there are issues around the implementation of leap seconds in
computer code that make my head spin.

Mike wrote -

>>>>simple arithmetic with a timescale with a variable second would
>>>>give an order of magnitude better estimate of the amount of time
>>>>between 2005 Dec 31 23:59:59.9 and 2006 Jan 01 00:00:00.1 than UTC
>>>>does!
>>>UTC will tell you that there is EXACTLY 1.2 seconds between those
>>>two points.
>>
>>The kind of "simple arithmetic" that I was thinking about precludes
>>the use of look-up tables.
> 
> Yet you consider quadratic equations to be "simple arithmetic?"

Simple arithmetic would give an order of magnitude better ESTIMATE. That
ESTIMATE would not require the use of quadratic equations. A PRECISE
answer would, but most of the general public are not as interested in
the kind of precision that you and I are.

And, from the point of view of programming, quadratic equations are much
easier to implement than look-up tables. And, from the point of view of
back-of-the-envelope calculations, it is much handier to do simple
arithmetic than to have to depend on having access to that damn piece of
paper with the look-up tables on it.

The error involved in not doing the quadratic conversion back from the
variable second timescale to SI seconds is approximately one part in 30
million at present. In a thousand years time, the error will have
increased to one part in about 2 million. This is way more precision
than is required (or even achievable) by the vast majority of people.

> >My suggestion does not call for a "loosely defined" second - it calls
> >for a variable second, PRECISELY tied to TAI. In other words,
> >time = a + b*TAI + c*TAI^2, where a, b and c are fixed constants
> 
> You'll need more than that. For a fixed set of coefficients, even for
> a limited period (~200 years) and relaxed sync with UT1 (2.3 vs. 0.9
> seconds) it takes a 12th order polynomial.

I'm a bit more relaxed than that! As I said, the general public seems
quite happy with time zones and daylight savings times that introduce
errors of over an hour to the time of astronomical midday. Indeed, China
has only one time zone in spite of its large size - I haven't done the
numbers, but I suspect that there may be people in China for whom
astronomical midday is at 10:00 (or earlier) or 14:00 (or later) clock
time.

> I think a lookup table is simpler,

Not if you have mislaid the piece of paper that has the damn lookup
table on it. And not if you need to program a computer system to do
time-based calculations (as opposed to programming a computer system
that just has to count time).

> more precise

Yes, but with waaaay more precision than the users of the timescale (the
general public) are interested in.

> and longer lasting.

I'm not sure I agree - but let's not fall out over it! :)

Unfortunately (IMO), inertia is on the side of keeping leap seconds.

Rob wrote -

> I have my own suggestion for how to handle civil time - since 
> rare events are harder to handle or to test, make them occur more  
> frequently:
> 
>      http://iraf.noao.edu/~seaman/leap

So I may have to update my eclipse-predicting program within a month of
the eclipse? I don't think so.

> Chris (O'Byrne?) says:
> 
> > Not even the venerable NTP will cause my computer to say "23:59:60".
> 
> [ ... ] Just thought you might find this technique useful.

If I'm reading your technique correctly, it is dealing exclusively with
input. I'm finding the issues of output to be more troublesome.

> If a project requires  
> unsegmented interval time, it can use TAI directly - or it can  
> correct UTC at the end points.

That is a bit difficult if the end points are on a leap second, and
impossible if the number of leap seconds between the end points are
unknown (ie one of the end points is sufficiently far in the future).

> absurdly claiming to correspond to "leap hours"

Yes. Leap seconds are absurd enough, leap hours are 3,600 times more
absurd!

Chris (O'Byrne!).




More information about the time-nuts mailing list