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

obyrne at iol.ie obyrne at iol.ie
Sun Jul 17 08:25:58 EDT 2005

```>: 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.
>
>Well, the varying length of a second is a non-starter, imho.

Why?

If you ask "most people", they will tell you that a second is one 86,400-th part of the
amount of time that the earth takes to rotate on its axis. Even though they don't know it,
such a definition leads to a variable duration of a second.

It seems to me that lots of people have timescales to suit their own needs - scientists
have TAI, and astronomers have all the rest :). But not everyone has a suitable
timescale - UTC is the timescale that's been introduced, it seems, for the benefit of
"most people", and it has serious shortcomings. If "most people" are already quite
happy with a variable second, then why not codify it? If "most people" want solar time,
and solar time is variable, then give 'em what they want!

Of course, the serious problem with a variable second is that of determining time
intervals - you cannot just subtract the earlier time from the later - you would also have
to calculate the appropriate scaling factor. But UTC isn't appropriate for determining
time intervals anyway! If you want time intervals, you use TAI - end of story. And, using
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!

>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

I suspect that mathematicians and computer programmers alike would prefer to use
quadratic equations than look-up tables, even if the latter are well-defined. Quadratic
equations are easier to work with than discontinuities. Also, continuing to use leap
seconds eventually leads to inserting leap seconds at the end of every month, week,
then day, though it may take 1,200 years before a leap second is required at the end of
each month. And, which would the general public prefer - a slightly, imperceptibly,
varying second that (attempts to) track the earth, or 23:59:60? Finally, over 400 years
ago, there was a change made to our calendar that is still in use today, and that looks
like it will still be in use 1,000 years from now (an impressive achievement by our
forebearers) - I think we should aim for such a long-term solution for the measurement
of the time of day.

>Perhaps you just want an argument (the arguers, not Chris specifically).

Nah - just trying to be helpful!

Just to introduce myself - I'm a professional programmer and amateur astronomer, and
my interest in precise time started with my involvement in a (professional) experiment
years ago to detect a pulsar. Two great memories I have from that time, both of them
arising from my confusion as to what a GPS receiver I was using was actually saying to
me about the time. One was when I was comparing the output of the GPS to the radio
time station RWM in Moscow - I saw that there was an 11ms discrepancy. This, I
decided, was because I was about 3,300 km from Moscow! The second great memory
was when I saw a one-second discrepancy between my understanding of the GPS
output and the national telephone time service (I'm in Ireland). I eventually tracked down
the people responsible for that time service, and asked them if they knew if or how
there could be a one second error in their clock. I had to explain to them that a one-
second error was actually very important to me as I was trying to measure time to
millionths of a second. I got as far as them asking me "oh - do you want us to reset the
clock?" before I gave up!

(Hence my belief that people would rather have the compromise of a varying second
than the 23:59:60 compromise).

Chris.

```