[time-nuts] (no subject)

Rob Seaman seaman at noao.edu
Mon Jul 25 13:59:22 EDT 2005


Sorry for the delayed response.

Chris O'Byrne said:

> my program could not be layered on TAI - why? Because TAI is not  
> available to the average user!

UTC *is* TAI, of course - with an integral number of leap second  
offsets.  The precision timing community could have spent the last  
6.5 leap second free years discussing how to improve the transport of  
leap second information and the underlying scheduling algorithm.

> The average user only has access to UTC, and so that is what I had  
> to use.

The average "user" (world citizen) has access to useful approximation  
of both Universal Time (Earth orientation) and Atomic Time  
(intervals) through one nifty UTC package.  One might entertain  
changing the policy such that only a single time scale is provided.   
I think this is dumb - but whatever.  But beyond dumb is the  
suggestion that we continue to call the resulting time scale "UTC".   
Call it something else.  We should protect the integrity of UTC just  
like we protect the integrity of TAI.

> Third, I could not access online sources of information - many  
> mobile phones don't have the infrastructural
> capability to access and parse on-line sources of information.

Just back from JavaOne.  Would suggest that you look at phones based  
on J2ME.

> Forth, of course DUT1 is also a problem for me, but it is a problem  
> that is significantly less important than leap seconds. A 0.9  
> second error in DUT1 corresponds to a 0.1 second error in the  
> observed time of an eclipse on the equator (the worst-case scenario).

And DUT1 is going to grow without bounds...

> Finally, of course I could have implemented something whereby the  
> users of the program had to manually insert the number of leap  
> seconds, but I SHOULDN'T HAVE TO!

Why not?  Because you say so?  Welcome to planet Earth, a  
decelerating platform that influences all sorts of observations.   
Your program presumably also has to have some notion of longitude,  
latitude and altitude.  Perhaps you get these from GPS?  GPS or NTP  
or WWV or other time protocols could be improved to do a better job  
of transporting leap second metadata.

> As a general citizen of the world, I am APPAULED that astronomers  
> can tell when an astronomical event years from now will occur to  
> within a fraction of a second, but they cannot tell me what time  
> will be on my
> watch at that time!

Are you intimating that this is some character flaw of these playboy  
academics?  Some measurements or predictions can be made very  
precisely and accurately a very long time in advance.  Others  
cannot.  A further welcome to the physical laws of the universe.

> Meeus wants to publish his predictions in UT, saying that its close  
> enough to UTC and hence the time people keep on their watches.  
> However, no-one can predict UT into the far future. If, on the  
> other hand, civil time were to be based on a quadratic equation in  
> TAI, it could be predicted far into the future, and hence Meeus and  
> others would be able to publish PRECISE lists of astronomical  
> events far into the future safe in the knowledge that if there are  
> no changes to the quadratic equation, their predictions would show  
> PRECISE clock time for those events.

You are suggesting a mechanism for adjusting the clock rates.  Others  
have done the same thing.  Before UTC, this is how civil time  
(implicitly time-of-day) and atomic time where synchronized.  I have  
no problem considering such mechanisms.  Such a discussion has  
nothing to do with the proposal on the table - or with engineers  
building systems layered on international standards.  Either a system  
agrees with the standards in place when it was designed and built -  
or it doesn't.  Either civil time is a representation of time-of-day,  
or it isn't.

> There is no solution that can simultaneously eliminate lookup  
> tables AND involve UT1. My solution isn't interested in UT1 - it is  
> interested in an approximation of UT1 that is accurate over the  
> long term (hundreds of years, maybe thousands), though may drift  
> (possibly horribly) over the short term. The vast majority of  
> people are not that worried about drifts that would (apparently)  
> horrify the subscribers to this list!

Presumably any eclipse prediction package needs to also predict the  
orientation of the Earth at the time of the eclipse.  Meeus' argument  
is that by constructing tables against Universal Time, that the  
orientation is known by definition.  He is talking about the best way  
to report data.  Your argument is that an underlying steady time  
scale permits separately solving for the position and orientation of  
Sun, Earth and Moon.  You are talking about a time scale internal to  
your algorithms.  You also have mentioned civil time as an input to  
your program.  Personally, I think the precision timimg community  
should be focusing on the best way to tie together inputs, algorithms  
and outputs in the richest possible temporal environment.

>> 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.
>
> Agreed! But my approach achieves both! (At least, to within many  
> parts per million - which is far more accuracy than most people are  
> interested in).

Your approach (or a variation) will achieve nothing if it isn't  
adopted as a standard.  A standard requires a clear statement of  
purpose.  I think the purpose should be to distribute a civil time  
standard based on time-of-day.

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

Opinions don't invalidate standards.

>> 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.
>
> I strongly disagree. As I said, I'm appauled that I have to depend  
> on some bureaucratic scientists in France before I can issue  
> useful, accurate eclipse predictions.

The IERS HQ may be in France, the decisions are made  
internationally.  I think all parties would appreciate a more formal  
scheduling algorithm, whatever it is.

> (By "useful", I mean predictions that are based on the time people  
> have on their wristwatches).

Precisely.  Useful time is easily accessible - and easily related to  
important things.  Solar time is arguably more important that  
"Eclipse" time.  Time-of-day more frequently encountered (for  
whatever purpose) than the consensus time scale of an ensemble of  
atomic clocks.

>> 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.
>
> I can see where you are going with this. Unfortunately, I cannot  
> see such APIs working on mobile phones, or on electromechanical  
> clocks for that matter.

Not a single word of the leap second debate over the past five years  
has had anything to do with electromechanical clocks.  Such clocks  
are frequently reset - a leap second is of no notable importance one  
way or another.

Future mobile phones and similar devices will contain Java VMs or  
similarly capable processing.  We should be discussing something like  
an XML standard for cleanly conveying time signals and ancillary  
metadata such as lists of leap seconds.

> I would be very much in favour of that if TAI were made as easily  
> available to the general public as UTC. Unfortunately, most  
> broadcast time services are set up to broadcast just one timescale,  
> and pretty much all clocks display just one timescale, and that  
> timescale is UTC, and is unlikely to change!

UTC is Universal Time joined to TAI.  Universal Time is an  
approximation of Greenwich Mean Time.  These assertions are true  
now.  They should remain so in the future.  If the world community  
wishes to layer civil time on some different underlying time scale,  
we should face the question head on and deal with the innumerable  
details similar to the discussion above.  If there is an interest in  
removing leap seconds from the civil time scale, that doesn't  
necessarily mean that leap seconds won't continue to be issued for  
other time scales (such as UTC).  Simply pick one of the many other  
non-segmented time scales to use as civil time.  Personally, I would  
suggest GPS.  The public has already been introduced to GPS, they  
like GPS, they understand (or think they do) GPS.  Live with the 13  
second jump (or whatever) to switch time scales - for many purposes,  
many clocks, this will be no more noticeable than 1 second.  For  
others, the unusual length of the jump will be a reminder that  
something extraordinary has happened.

And most important.  At some future date, when we have decided that  
civil time really ought to have remained a representation of time-of- 
day, we will be empowered to make the opposite switch back to UTC.   
UTC will have continued to include leap seconds - astronomers will do  
it if nobody else - and nothing will have been unilaterally broken by  
an insane attack on UTC itself, rather than on the civil time  
standard that happens to *reference* UTC.

UTC is not civil time.  Civil time at the current epoch uses UTC.   
UTC has a life of its own.

Rob Seaman
National Optical Astronomy Observatory




More information about the time-nuts mailing list