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

obyrne at iol.ie obyrne at iol.ie
Sun Jul 17 18:24:18 EDT 2005

```>>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.

>No estimation needed, so it would be infinitely better than some loosely
>defined variable second.

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 chosen in
such a way that "time" follows UT in the long term, though drifts against
it in the short term (the constant "a" would approximate the difference
between UTC and TAI at the time of introduction, "b" would essentially be
unity, and "c" would be quite small). All time systems would keep TAI
internally, and convert it to "time" for presentation to the user as
needed.

>One must understand that UTC does not follow the _convention_ that all
>minutes have 60 seconds.

This is where I have a real problem. Who is UTC meant to serve? Because if
it is meant to serve the general public, I think you will find that the
general public defines a minute as a period of 60 seconds - no more, and
no less.

If UTC isn't meant to serve the general public - if it is instead meant to
serve astronomers and/or time purists, then I think we need a timescale that
IS meant to serve the general public.

>If one claims that leap seconds make UTC "discontinuous" by some other
>definition, one must then admit that leap days make most other time scales
>discontinuous also, for they are logically equivalent, differing only in
>the amount of time before irregular corrections need to be applied (years
>for leap seconds/UTC, millenia for leap days/Gregorian).

OK - "discontinuous" was a bad choice of word on my part.

>33 years to work this out, but haven't for the most part.

After 33 years I think it's time to say - UTC has failed. It was a bad
idea IMO.

>Now they want to fundamentally change UTC (breaking systems which DO use
>UTC as intended) to make up for their inaction.

Laziness isn't the reason for the lack of action IMO - the reason for the
lack of action is that it is a difficult thing to do right! It looks easy,
it sounds easy, but it's actually not. There doesn't seem to be any argument
between us that the non-forecastability of leap seconds is a major part of
the problem but, actually, the leap seconds themselves are also a problem.
Why? Because a 60-second minute is ingrained. For instance, what should
analogue clocks do this December? How can I write a java-based analogue
clock that is UTC-compliant?

You mention that this will break systems that DO use UTC as intended. The
only such systems that I'm aware of are GPS receivers (many of which will
output 23:59:60 this coming December). Not even the venerable NTP will cause
my computer to say "23:59:60". Out of curiosity, what other systems are leap
second aware? Are there any systems with high public visibility that are
leap second aware? Given that I'll be in the "GMT" timezone, is there
anywhere I can bring my friends this new years eve where we can simultaneously
sit down and have a nice beer AND witness the extra second before the start
of 2006?

>>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.
>
>The Gregorian system slips about 1 day every 4000 years. Considering that is
>shorter than recorded history, and very much less than human existance, I
>consider that less than "long term."

I did say "aim for...". Also, 4,000 years is a lot longer than the 1,200 years
or so that the current definition of UTC can possibly work for.

Chris.

```