Leap Second Report (fwd)
Markus.Kuhn at cl.cam.ac.uk
Wed Jul 5 15:36:18 UTC 2000
You might remember the USNO survey on the redefinition of UTC a few
months ago. Here is their report on the results, which I guess might be
of interest to some here.
[My own reply then in a nutshell was not to abandon leap seconds, but
perhaps to announce them much longer in advance (say 25 years), even if
this means |UTC-UT1| > 900 ms sometimes temporarily.]
------- Forwarded Message
Date: Wed, 5 Jul 2000 14:23:34 GMT
From: Demetrios N Matsakis <dnm at orion.usno.navy.mil>
Subject: Leap Second Report
Thank you for having responded to, or somehow been connected with, our
questionnaire concerning the effects of a redefinition of UTC.
If you are interested in pursuing this issue, we welcome you to join our
listserv "chat group", http://clockdev.usno.navy.mil/archives/leapsecs.html.
Report of the URSI Commission J Working Group on the Leap Second
Date: July 2, 2000
Abstract and Conclusions
An e-mail survey to find possible adverse effects of a redefinition of
UTC has identified some possibly expensive or unsolvable problems
involving software rewriting or checking, which are listed below.
Although it was not possible to quantify the financial scale of
resolving the software problems, the largest expenses appear to be for
satellite systems, of which one estimate of several hundred thousand
dollars was supplied. The quantity and quality of the responses
opposed to a change indicate that those who favor any change must be
prepared to make a very convincing argument to people and groups who
initially will disagree with them.
To further discuss this issue and inform the community of any developments,
an archived electronic listserv has been set up. Anyone wishing to join
can do so using http://clockdev.usno.navy.mil/archives/leapsecs.html.
UTC (Coordinated Universal Time), which the public commonly confuses
with Greenwich Mean Time, is computed by occasionally adding leap
seconds to International Atomic Time (TAI). Since 1972, these leap
seconds have been added on December 31 or June 30, at the rate of about
one every 18 months, and serve to keep atomic time in step with the
Earth's rotation. Although it is recommended that users use only TAI or
UTC, as their needs indicate, many major navigation system have used
times offset from TAI by fixed amounts. The most important of these is
GPS, which is offset by 19 seconds from TAI.
A segment of the international timing community has proposed a revision
of the definition of UTC to avoid the discontinuities due to
intermittent leap seconds. A discussion of the motivations for a
change and of possible solutions has been published by McCarthy and
Klepczynski in the Innovations Section of the November, 1999 issue of
GPS World. The authors consider the most significant reason for a
change to be keeping spread-spectrum communication systems and
satellite navigation systems compatible with each other and with civil
times. Another reason is the emerging need in the financial community
to keep all computer time-stamps synchronized.
In order to survey the effects of any action, an URSI Commission J
Working Group (WG) was formed, whose purpose was to prepare this report
and propose further actions.
A questionnaire (Appendix I) was distributed as widely as seemed
appropriate (Appendix II). The goal of the questionnaire was to find
and categorize those operations that would be adversely affected should
a change in UTC's computation be made. The questionnaire focused on the
possibility of simply inserting no new leap seconds, although
alternative solutions were also solicited. Over 200 responses were
received, and no effort was made to separate the responses of URSI
members from those of nonmembers.
The principal object of the questionnaire was to find what systems
would be adversely affected should a change be made in leap second
procedures rather than to convince users of the need for a change or
to take a vote. However, so many queries on these matters were
received that a "standard reply" (Appendix III) was developed and
distributed as appropriate. In the spirit of full disclosure, the
number of responses in each category is given, but we caution that this
was by no means an unbiased sampling of all who would be affected by
the change. All responses were counted only once, with preference to
the most practical grounds for objection. About half the responses
that were received were opposed to any change, while one-fourth were
in favor of a change, and one-fourth indifferent.
I. Responses Opposed to Changes in the Status Quo
A. The expense of rewriting software.
Five responses suggested that contractors would have to be hired to
scrutinize and adapt large amounts of code for operational satellite
systems. Efforts were made to contact these responders for specific
dollar amounts, and one off-the-cuff estimate of "several $100,000" was
received. The impact on such systems would be lessened if any decision
to redefine UTC were announced several years in advance.
Twenty-six others indicated that software would be a serious problem - a
very few of these were from people who did not seem to understand the
proposal. There were 9 responses involving telescope control; one of these,
from the Keck Observatory, provided a rough estimate of a few programmer-
months. Others pointed out the problems computing eclipses and
occultations, for telescope pointing by amateurs, or with code they had
themselves written for professional-level projects such as speckle
interferometry. One observatory indicated its station clock can not
accommodate a large UT1-UTC correction.
Fourteen more indicated that software issues would be a problem, but that
they are probably solvable. Some of these actually indicated support
for the change.
B. Inherent inability to rewrite software to allow for |UT1-UTC|
exceeding .9 seconds.
Ten responses involved navigational software. Taking the example of a
software product of the US Naval Observatory (USNO), pilots and sailors
are given the option to input UT1-UTC. However, it is expected that
many users would not understand this and enter 0, leading to noticeable
errors within a decade. These are similar to the telescope-control
problems covered above, except that one could not and should not expect
the general public to ever understand these issues. Problems amateur
astronomers might have are also included here, and were brought up by
many responders in other contexts.
One of the problems anticipated is that UT1-UTC could be applied with
the wrong sign, just as the leap second is occasionally applied with
the wrong sign. An example of "buffer overflow" problem would happen
in NIST's WWV, WWVH and WWWB transmissions, which do not allow enough
space for |UT1-UTC| to exceed .9 sec. Any users of these broadcasts
who might need this information and who are unaware of the problem,
decoding in hardware, or relying on old software would be adversely
affected. Under the best of future circumstances only the sub-second
(tenths) digit would be available, requiring the user to keep track of
the digits to the left of the decimal point.
Not tabulated is an informal comment seriously made to the Working
Group's Chairman, by a respected and competent scientist from a
non-western nation, that astrologers would be adversely affected.
C. Philosophical Objections
Eight thought this would confuse or antagonize the public, religious
authorities, or even scientists - in essence because solar time is
"true time". (In contrast, one responder in favor of a change thought
this would help educate the public to the fact that Earth rotation is
not "true" time).
Three pointed out that legal complications might occur in countries
where laws are specified in terms of solar time, or GMT (which has not
existed for thirty years). Although one of these responders feared
governments would not follow the scientist's lead, we find it difficult
to believe that governments would, on their own, choose to add leap
seconds. Others thought that any legal system flexible enough to
handle daylight savings time and the past abandonment of GMT in favor of
UTC would easily accommodate a seamless change in UTC's computation,
especially if no other time standard were available. Some of the
history of legal issues concerning past changes in time definition can
be found in the book "Greenwich Time and Longitude" by Derek Howse.
Three thought we should not adopt a system which will fail in the long
run, even if that is a very distant time in the future. (It could be
pointed out that all current time systems will eventually fail. Well
before 2050 we could be routinely adding more than one leap second per
year, and when we reach the point where a day is 48 hours long we
would have to add a leap second every second. Even the Gregorian
calendar will eventually need revision because in a few million years
the Earth will rotate less than 365 times per year, and leap days will
not be necessary.)
Two thought this would deprive the timing community of free publicity
when leap seconds are inserted.
Thirty-eight expressed opposition, but gave no specific reason. Eleven
of those also indicated that a problem would exist with their system,
but did not specify it. Some of these pointed out that TAI was readily
available, or indicated that they had seen no justification for a
change. (We had intentionally provided no justification in the initial
questionnaire, but two responders replied that they still believed
there was not enough reason to change even after having read "standard
Four were against it because they thought problems would happen if some
systems did not use the new system, and because they thought one would
have to separate analyses based upon whether data were recorded with
the current system or the old system. (We believe these to be based
upon a misunderstanding of the "no new leap seconds" proposal, but
entirely possible if the more drastic measure of re-defining SI, the
International Second, were adopted.)
II. Alternative Suggestions
Five suggested that it would be better to redefine the second to be
longer, add 1 second every 18 months forever, change on leap years or
century-ends, or change when the number exceeded a fixed amount. These
possibilities are also discussed in the GPS World Article.
A suggestion was received to add enough "negative leap seconds" to
bring UTC in line with GPS. However, a different responder pointed out
that many of NASA's programs assume UT1-UTC always grows and that
problems would happen with any change that would sometimes lead to a
"negative leap second". (According to Dennis McCarthy of the USNO, this
is possible even with the current system, but unlikely).
It was also pointed out that rubidium atomic fountains or optical
standards could lead to a redefinition of the second using an element
other than cesium. If so, it could be redefined using a scale factor
of sufficient magnitude to avoid the short-term need for leap seconds
(As noted in the GPS World article, such a change would alter the
values of those physical quantities that depend upon time.)
One suggested that a redefined UTC should have a new name.
III. Responses in favor of changing the current leap second procedures
Forty-eight responses in favor were received, several from people who
experienced minor problems now in handling leap seconds, such as
confusion due to GPS time being currently 13 seconds offset from UTC
and computer errors at the time of the leap seconds. Along with
responses based upon reasons already covered in the GPS World Article,
there were also three from the highly undersampled group of computer
programmers, which pointed out the growing need to synchronize diverse
computers to one second accuracy and the difficulties of doing so in an
when dates of future leap seconds were unpredictable. Many of the
responses indicated that periodic addition of leap seconds on a scheduled
basis would also be acceptable. One of the responders, who was opposed to
a change, suggested that leap seconds were not a problem because computer
users could program an automatic extraction of the needed information from
some publicly available source; however it must be pointed out that no
one can guarantee that a given file, whether it be for leap seconds or
for daily values of UT1-UTC (see part IV, below), will remain forever
available in a given format or given IP address.
Four responses were from people who indicated that the convenience in
not having to update files every 18 months outweighed the expense and
problems rewriting software. One of these suggested the use of
sufficient negative leap seconds to bring UTC in line with TAI, and
several noted that UT1-users easily incorporate the offsets due to
time zones and daylight time.
IV. Other Responses
Forty-seven responders checked the "indifferent" option. Most
indicated that there would be no problems with their system, or that
the problems were small enough that they were indifferent to a change.
Seven other responders indicated that the change would be okay if they
could somehow reliably obtain UT1-UTC. (The USNO, as a sub-bureau of
the IERS, freely provides this information on its web site, http://www.
maia.usno.navy.mil, and via weekly emailings. Other organizations also
provide this information.) Some responses tabulated here were phrased
in the negative because the responders were apparently unaware that the
information was available. One responder was concerned that the GPS
system itself would be degraded for this reason, however this is not
the case because GPS currently uses UT1-UTC values derived from USNO
Appendix I. Questionnaire
It is being proposed to change the definition of Coordinated Universal
Time (UTC) regarding the insertion of leap seconds, possibly even
eliminating their use. Leap seconds are introduced so as to keep UTC
synchronized (within 0.9 s) to the time scale determined from the
Should no new leap seconds be inserted, solar time will diverge from
atomic time at the rate of about 2 seconds every 3 years, and after
about a century |UT1-UTC| would exceed 1 minute. Although no
fundamental problems are anticipated, it is very likely that Y2K-like
problems may result in software that assumes UT1=UTC, or |UT1-UTC|< some
value, or whose input/output records use a field size that can only
accommodate |UT1-UTC| values up to one second.
To gather information, an URSI Commission J Working Group was formed,
consisting of Don Backer, Wim. N. Brouw, Barry Clark, Irwin Shapiro,
Ir. E. Van Lil, with Demetrios Matsakis being the chair.
We would like to ask you to consult with the members of your institute
who currently deal with UT1-UTC, and give us a considered response to
the following two questions:
A. If the appropriate international bodies decide to eliminate the
insertion of new leap seconds, would you foresee any practical problems
for your institution/instrument/observations?
* yes ___
* possibly ____
(* please explain any known or possible problems)
B. Would you be in favor of such a proposal?
have better idea ___
(feel free to comment)
C. Is there anyone else you would recommend we contact?
(feel free to forward this email directly)
I would appreciate your assistance, and a response by January 15 to
dnm at orion.usno.navy.mil.
I am attaching a list of institutions and persons contacted, except
for 931 institutions whose emails were obtained from the AAS. I would
like to apologize to anyone contacted twice, but also appreciate it if
you would forward this email to anyone we have missed. Also, if you
are an URSI Commission J national chair, we would appreciate your
forwarding this email to your complete membership and in particular to
the directors of observatories.
Dr. Demetrios N. Matsakis Director, Time Service Department
(202) 762-1587 DSN 762-1587 U. S. Naval Observatory
FAX (202) 762-1511 3450 Massachusetts Avenue NW
dnm at orion.usno.navy.mil Washington DC, USA 20392-5420
Appendix II. Distribution List
Efforts were made to conduct an international survey, and responses
were received from Europe, Japan, China, Australia, Canada, Russia,
Saudi Arabia, Brazil, and other countries. The majority of the
responses, however, were from the U.S. Commercial interests, such as
satellite companies, were highly undersampled. The questionnaire asked
people to forward it to others, and we know the following were
1. 128 prominent scientists, who were mostly URSI Commission J members
and official representatives of institutions associated with URSI.
2. 27 URSI Commission J national chairs.
3. 931 Institutions extracted from a database kept by the American
Astronomical Society, including many from outside the United States.
Several hundred of those email addresses proved invalid.
4. All on the USNO Series 7 mailing list.
5. All on the "Gazette" mailing list of the International Earth
Rotation Service (IERS). This would be expected to include most
scientific groups that are directly involved with UT1.
6. One responder who worked in SETI indicated he had forwarded it to
7. The Internet Engineering Task Force's mail exploder.
8. One responder, who was against any change, indicated he had forwarded
the questionnaire extensively around Jet Propulsion Labs (JPL).
Appendix III. "Standard Reply" to queries concerning the questionnaire
Thank you for your response, which will be tabulated. Unix-technology
willing, we also plan to send a copy of our report all responders.
Many people have asked me why there is a move to rethink the leap seconds,
with solutions such as (but not limited to) adding no new leap seconds.
I unfortunately edited out some of the reasons from early drafts of the
questionnaire, because I was afraid that people would not read a long email.
Since then, I have developed the following "standard reply":
1.) Many high-tech navigation systems, particularly those using
spread-spectrum techniques, can't handle leap seconds very well.
GLONASS, the Russian equivalent to GPS, goes off-line for leap second
adjustments. Also, problems can occur in interfacing between systems that
handle leap seconds differently. There is also the practical problem of
inserting a second every year and half - people often do it the wrong way.
The response one person sent me is below, and it concerns Network Time
Protocol (NTP), which uses the internet to transfer time.
> If leap seconds went away, the NTP community would worship the ground you
> walk on. Leap secs introduce a manual discontinuity in the NTP time scale.
> It takes a while to propagate leap secs through the hierarchy. Leap seconds
> are a tremendous headache in the NTP world because they cannot be predicted.
> One must set a flag to indicate that one is coming. I think it is a very
> true statement that all GPS users would vote against continuing leap seconds,
> not just NTP users. Many telecommunications circuits use GPS or atomic clocks
> to keep cellular phones in operation, and leap seconds are a nuisance to them
> as well.
2.) I also received many comments about the effects on society when UT1
diverges. Note that we are talking about a minute in the next century.
Society routinely handles a one-hour switch with every daily savings time,
and a half-hour offset if they live at the edge of a time zone. By
the time leap seconds add up to an hour, the world will be very different.
If we have settled the solar system, a whole new scheme will probably
have evolved. Even if we have not changed our system, society has
enough slop in its timekeeping that people will slowly shift without even
knowing it. More people will start showing up to work at 9:00 AM, and less at
8:30 AM, etc.
3) The "Innovations" section in November's GPS World is on this subject,
and discusses other possibilities aside from "no new leap seconds". These
are inserting larger discontinuities less frequently, inserting integer
leap seconds at predefined times, simply using TAI, and redefining
the length of the second.
4) It should be pointed out that UT1-UTC is readily available on the web.
The USNO, as a subbureau of the International Rotation Service, makes
this information available via a weekly mailing and from a web page
at http://www.maia.usno.navy.mil, and other organizations also provide
5) My final comment is not to worry about any "surprise" decisions - before/if
the international bodies all decide to do this, it will be fully debated and
publicized. My role, here, is simply to gather information.
------- End of Forwarded Message
More information about the tz