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