Today is one of the four days in the year when Newcomb's expression
for the equation of time has a value of zero. In honor of Simon
Newcomb I offer the following notions for changing the way that
leap seconds are scheduled. I suspect that this is almost certain
to offend everyone. Perhaps for that reason it is workable.
I would not be surprised to learn that the Time Lords are already
contemplating a scheme akin to this one.
========================
Let the date of adoption of the new scheme be YA.
======During the first five years after the year of adoption.
(YA through YA+4)
Basically the status quo.
Leaps are announced as early as possible, and they are scheduled
only on the end of June+December dates.
======During the second five years after the date of adoption.
(YA+5 through YA+9)
On a semi-annual basis the IERS should publish an immutable schedule
of leap seconds predicted for five years into the future.
The pre-scheduled leap seconds will occur only on the semi-annual end
of June+December dates.
Beginning at YA+5 any application can always count on having a five
year lookahead for knowing when leap seconds will occur.
Along with the immutable schedule for five years into the future,
also publish a provisional schedule of leap seconds for the five
years beyond that, also on the June+December dates.
Beginning at YA+5 that will mean that the total span of provisional
schedule extends ten years into the future. If there are any devices
that cannot have their leap second tables updated within five years
they will still have a pretty good notion of TAI-UTC for ten years.
======Starting ten years after the date of adoption.
(YA+10 until further notice)
On a monthly basis the IERS should publish an immutable schedule
of leap seconds predicted ahead for the next five years.
The previous scheme means that for five years after this
(from YA+10 through YA+14) the leap seconds will occur only on the
June+December dates.
Starting with the first monthly leap prediction after YA+10 the
pre-scheduled leap seconds may occur on the last day of
any UTC month.
That means that starting with YA+15, leap seconds may occur
monthly, as is already specified by the UTC standard.
Along with the five-year immutable schedule published monthly, the
IERS should continue to publish the provisional schedule of leap
seconds for the next ten years. This will preserve the ten-year
provisional lookahead for any applications which may not be able to
update their firmware within five years.
======Educate, educate, educate.
This should start even before the date of adoption YA.
The ITU-R should openly publish the UTC specification.
Each bureau of the IERS which issues any bulletin should obtain or
create a digital certificate to be used for authentication.
Each bureau of the IERS which issues any bulletin should define
an XML schema as the canonical form in which it issues each bulletin.
The XML schema should allow a W3C Signature element which permits
the content of the bulletin to be digitally signed for authenticity.
Along with the XML schema each bulletin should publish an XSL
translation which can be used to convert the canonical XML form
into a plain text form which matches the currently existing documents.
The IERS should enter into dialog with the International Virtual
Observatory Association (IVOA) and the Internet Engineering Task Force
(IETF) to determine an adequately robust scheme for guaranteeing the
distribution and availability of the XML documents which give the
schedule of upcoming leap seconds.
========================
Here I ruminate on my scheme.
The five-year pedictability is primarly a concession that the
difficulties oft mentioned by Poul-Henning Kamp and M. Warner Losh
may need to be addressed.
Currently any applications which need to predict local civil time
accurate to better than an hour are impossible. This is because
governments/legislatures/parliaments/etc. responsible for deciding
on the dates of daylight/summer time keep changing the rules with
only around a year of advance warning (and in some cases much less).
My proposed changes do not alter this situation. Applications which
need to predict the number of seconds until some local civil time
will be just as impossible in the new scheme as they are now.
On the other hand, I think it would be interesting if a scheme such as
this made it clear to politicians and bureaucrats that predictability
of civil time is so very important that they had better start issuing
daylight/summer time rules with five years of advance notice. In this
sense scientists might actually be seen to be leading the way toward a
better world for all.
I considered a window larger than five years, but I realized that I
would be very uncomfortable trying to swap in a spare computer which
had lain on a shelf for five years with no updates to its operating
system or firmware. Unless the pace of computer hardware evolution
and discovery of security holes in software slows considerably I
think that five years is a pretty good window.
As the five year prediction scheme goes into effect this will probably
mean that there will be times when UT1 - UTC exceeds 0.9 seconds, but
not by very much.
Most telescope pointing systems fall into two classes:
1) telescopes that point like battleships (because they were built as
such) and have manual corrections performed by humans.
2) telescopes that point robotically and use a table of predicted
values for UT1 - UTC published by the USNO branch of the IERS.
The former will hardly notice the excursions larger than 0.9 s.
Most of the latter probably do not have their software check to see
whether the excursions are larger than 0.9 s.
The effect on civilian life will be indistinguishable from status quo.
Sundials will do just as well then as they do now.
I am still not convinced that there is any need for change. I would
like to see further examples of why the status quo is not tolerable.
In recent months I've done a lot of testing of my asbestos suit.
Fire away.
--
Steve Allen <sla_at_ucolick.org> WGS-84 (GPS)
UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99858
University of California Voice: +1 831 459 3046 Lng -122.06014
Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
Received on Thu Apr 13 2006 - 22:41:24 PDT