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

Rob Seaman seaman at noao.edu
Mon Jul 18 15:26:47 EDT 2005


Chris O'Byrne says:

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

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

> 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?

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.  The IERS and such folks do a very  
good job of this actually, but over the long term it is simply not  
deterministic.  Just like the artificial focus on conversions between  
US units and metric units, this discussion misses the point.  Using  
the metric system doesn't intrinsically require converting back-and- 
forth to US units.  Using UTC (or UTC+DUT1 as an approximation to  
UT1) doesn't typically require converting back-and-forth to TAI.  See  
Jean Meeus's discussion:

     http://www.ucolick.org/~sla/leapsecs/onlinebib.html#Event2005-07-08

(I'm sure anybody with your avocation is familiar with Meeus.)

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

The difference between a lookup table and a closed form solution that  
can be embedded within code is a coherent strategy for issuing events  
responsive to the appropriate closed form approximation.  A  
particular program can be based on any ephemeris that makes sense.   
This could then be pushed through a leap second scheduling algorithm  
to interpolate the intervening leap seconds.  See my discussion in  
http://iraf.noao.edu/~seaman/leap.  What is missing here is a  
coherent leap second scheduling algorithm.  The IERS chooses each  
leap second manually by some committee vote - they should adopt and  
use a specific strategy instead.  Minimizing |UTC-UT1| is a good  
start for developing such a strategy.

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

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

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)

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.

Rob Seaman
National Optical Astronomy Observatory




More information about the time-nuts mailing list