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
_______________________________________________
time-nuts mailing list
[email protected]
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
