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

Rob Seaman seaman at noao.edu
Sun Jul 17 20:28:56 EDT 2005


Thanks to all for the excellent discussion - over the past five years  
I've seen much less diplomatic discussions on the issues.  It has  
never bothered me that folks hold a diversity of opinions on UTC -  
time is a deeply interesting subject worthy of our best efforts.  Any  
solution(s) worth implementing must be able to withstand  
confrontation with withering criticism.  Here is another discussion  
as to why the proposal to simply halt leap seconds is failing to  
survive such criticism:

     http://www.cl.cam.ac.uk/~mgk25/time/leap

Markus Kuhn also has a proposal for how to handle leap seconds cleanly:

     http://www.cl.cam.ac.uk/~mgk25/uts.txt

Others (here also) have proposed similar time-slicing mechanisms.

It is inevitable that time standards will remain a perpetual focus  
for international discussion.  This does not worry me.  What worries  
me is an attempt to sweep time once-and-for-all under the rug.  This  
cannot possibly succeed and we will regret it - sooner, rather than  
later.  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

Comments on specific issues raised:

I said:

>> Straightforward algorithms (a few lines of C) can convert  
>> standard  time to local time and mean time to apparent time.

Robert Lutwak replies:

> It ain't "...a few lines."  Properly dealing with timezones,  
> daylight savings, and leapseconds can easily run into thousands of  
> lines of code, by the time you include of of the oddball  
> irregularities around the world.

Note that I said LST -> LMT and LMT -> LAT.  The boundaries of  
timezones and the varying rules of daylight saving weren't  
mentioned.  On the other hand, on any given date, TZ and DS could be  
expressed in a few tens or hundreds of kbytes worldwide.  The biggest  
complication is that particular nations, provinces or states can  
change these rules at any time.  You want to lobby to simplify time  
handling procedures, work to implement an international standard for  
these, don't muck with leap seconds.

As far as LST -> LMT -> LAT, the proposed abandonment of time-of-day  
means that these currently simple closed form algorithms will become  
as complicated and subject to error as timezone/DS handling is  
currently.

Poul-Henning Kamp says:

> "Ignore this planet".

No comment.

Bill Hawkins says:

> Yes, the Arabians have 15 minute increments for local time jumps.   
> I don't see thousands of lines of code to do that.

Arizona (where I'm located) has no daylight saving (the last thing we  
need to save is daylight) - except that the Navajo's do have DS (the  
reservation overlaps Utah and New Mexico and presumably they want to  
keep synchronized) - except that the Hopi reservation (completely  
surrounded by the Navajo) do not have DS.

Just a reminder that 21st century time standards must continue to  
support a wide cultural diversity.

M. Warner Losh says:

> (2) Leap seconds can be both positive and negative

We don't have leap seconds because the Earth is spinning down.  We  
have leap seconds because the Earth has already spun down relative to  
the 19th century epoch when the length of the second was codified.   
(The definition of the second has changed, but not its size.)  This  
is precisely why leap seconds are quadratic over long periods of  
time.  And this is why a negative leap second is extremely unlikely  
(and becoming less so) - not only would the Earth have to spin up, it  
would have to spin up enough in a year or two to counteract more than  
a century of accumulated slowing.

Robert Lutwak says:

> I'd say y'all are underestimating the power of adaptive evolution.

No comment.

M. Warner Losh says:

> I forgot to add that in between 1200 and 2100 years the current  
> interneational standard of one leap second per month will be  
> insufficient to accomidate the drift.  So talking about what  
> happens in 10,000 years is already well beyond the current  
> standards, so something *HAS* to change before then...

Yes, over the long term we have a worthy challenge to address - I  
hesitate to say "solve" because I don't think a simple solution will  
suffice.  We should be addressing a viable long term time handling  
strategy, not looking for an easy way out.  And the current standard  
provides hundreds of years to discuss the issues.

Poul-Henning Kamp says:

> I just don't see how anything should break because of missing leap  
> seconds.

Absence of imagination is not evidence of absence.

> The only way this can happen is if you use your time against an  
> object which is not terrestial:  Ie: you are an astronomer.

Many programmers are troglodytes - but that doesn't mean that the Sun  
doesn't exist.  Time-of-day is solar time.  There are many natural  
and man-made solar system objects that we depend on every day.  The  
orientation of those objects with respect to locations on Earth is  
often important.  The orientation of objects on Earth with respect to  
solar system objects is often important.  (Often can be defined in  
terms of how frequently leap seconds are likely to adversely affect  
other systems.)  Forget about those pesky stars, galaxies, quasars  
and other cosmic chaff.

> But the most cost efficient solution is to redefine UTC, rather  
> than trying to reeducate people who have already ones failed to  
> understand the topic.

If the failure is educational, the solution must be educational.   
Cost is not the only parameter that must be optimized.  Trying to  
optimize cost without handling performance and schedule (to name two  
other parameters) is likely to ultimately result in the cost  
ballooning out of control.

Bill Hawkins says:

> The Moon does not cause leap seconds. That effect is measured in  
> milliseconds per century.

The Moon *caused* leap seconds (was the largest effect in the  
lengthening the day since the 19th century).  Let's see - back of the  
envelope:  lunar tides cause the day to lengthen 20 seconds every  
million years.  This angular momentum is transferred to the moon's  
orbit.  Laser reflectors left by Apollo show the orbit will grow 20  
miles in a million years.  Every second's increase in the length of  
the day is bought by moving the moon a mile farther from Earth.  On  
the other hand, leap seconds are the result of aggregating  
millisecond differences in the length of the day over several hundred  
days.

Chris (O'Byrne?) says:

> Not even the venerable NTP will cause my computer to say "23:59:60".

I workon a widely used astronomical image processing package (http:// 
iraf.noao.edu).  IRAF defines a sexigesimal value as a floating point  
number (typically a double).  Wherever a floating point value can be  
supplied, a sexigesimal value is acceptable.  We have a %h printf  
directive that provides the reverse conversion.  As with similar   
situations, the rule is to be strictly compliant when writing a value  
(printf minute and second fields are bounded less than 60), but  
loosely compliant on reading.  These are perfectly legal values on  
input:  25:00:00, 23:60:00, 23:00:60, etc.  Just thought you might  
find this technique useful.

Bottom line:

Every year or two (or seven) we have the opportunity to tweak civil  
time to more accurately reflect time-of-day.  During the intervening  
months, civil time provides an excellent standard equalling TAI 
+offset.  If a project requires time-of-day, it can currently simply  
use civil time.  This is very handy.  If a project requires  
unsegmented interval time, it can use TAI directly - or it can  
correct UTC at the end points.  Your choice.

The proposal on the table does not eliminate the underlying  
requirement for civil time to track time-of-day.  Rather, it simply  
denies the roughly annual (or strictly monthly as I argue at my link  
above) *opportunity* to resynchronize civil time and time-of-day.  If  
we continue leap seconds past 2007-12-21, we will have another chance  
to revisit that decision within a year or two (or maybe seven).  On  
the other hand, if we switch to a scheme absurdly claiming to  
correspond to "leap hours" - we will have no opportunity to cleanly  
revisit the decision for hundreds of years.

Time requires our best efforts - not those deemed by a few to be most  
expedient.

Rob Seaman
National Optical Astronomy Observatory




More information about the time-nuts mailing list