Recently I ran into a document at NIST that describes the place
that the ITU holds in the hierarchy of international organizations.
http://www.boulder.nist.gov/timefreq/general/pdf/982.pdf
This document also describes the process through which the ITU is
supposed to make changes in things related to time and frequency. I
found this particularly interesting because some of the transcripts
from early presentations by SRG 7A hinted that it took a while to
determine the protocols by which they should operate.
Another curious thing has been to look at the results of Google
searching various weblogs, discussion groups, and other documents that
mention leap seconds. Given the nature of internet discourse it is
not at all surprising to see that people who are not familiar with the
subject often start threads asking what leap seconds are, when they
happen, and why they are necessary. It is surprising to see that the
right answers are often not supplied. Unfortunately, misconceptions
about leap seconds are not confined to casual discourse.
As late as 1997 the Unix specification provided for double leap seconds
http://www.opengroup.org/onlinepubs/007908799/xsh/time.h.html
Just perform a Google search on "double leap second" to see the number
of instances of this misinformation. On the web there are literally
hundreds of copies of documents based on this spec, and there are at
least three obvious variations in the wording of the phrase mentioning
"double leap seconds" which implies that the mistake migrated from one
standard into others. According to a posting by Markus Kuhn
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=6urcfr%24s01%241%40pegasus.csx.cam.ac.uk
the "double leap second" misconception arose in a 1989 standard.
It appears that a number of contributors to LEAPSECS were involved in
the subsequent discussions where the actual content of ITU-R TF.460
was introduced and resulted in the removal of the language regarding
double leap seconds. See, e.g., messages in these contexts which
indicate that the requests to remove double leaps did not begin until
the year 2000
http://www.opengroup.org/sophocles/show_archive.tpl?source=L&listname=austin-review-l&first=1&pagesize=80&searchstring=UTC&zone=F
http://www.opengroup.org/sophocles/show_archive.tpl?source=L&listname=austin-group-l&first=1&pagesize=120&searchstring=epoch&zone=G
That Unix and C language standards could contain such a glaring
discrepancy for over a decade raises the question of how their authors
could be unaware of the circumstances under which leap seconds are
introduced. I will suppose that the proprietary nature of ITU
documents is one of the principal reasons.
When the CCIR first instituted leap seconds they guaranteed that the
distinction between time-of-day and standard time interval (and
frequency) would continue to remain irrelevant to most systems of that
era. The near indetectability of leap seconds removed the need for
recommendation TF.460 to be widely available. In the ensuing years
leap seconds became detectable by many more systems. Standard
specifications and systems seem to specify UTC even when they do not
understand the implications of doing so. There are many mistaken
impressions about the way that leap seconds are implemented. The
incommensurate distinction between standard time interval and
time-of-day remains obfuscated, and there is a general lack
understanding of the motivating reasons behind the existence of the
current scheme of leap seconds.
Should the standard that defines civil time around the world be a
document whose distribution is restricted in any way?
Curiously, through a combination of legal actions, ITU-R TF.460 came
close to being declared in the public domain in the United states. On
2002-11-19 bill S 3177 was introduced in the US senate, presumably by
the actions of various people at NIST. The text of the bill is
visible at
http://thomas.loc.gov/cgi-bin/query/z?c107:S.3177:
The bill did not get past committee, but it contained language that
would have modified 15 USC 261 to define the standard time zones in
terms of UTC instead of the mean solar time of Greenwich.
Independent of that senate bill, the legal case of Veeck v. SBCCI was
also proceeding. Details of that case can be found via
http://regionalweb.texoma.net/CR/index.htm
Basically, as a result of this case it has been established that the
law in the United States must be in the public domain, and this holds
true even if the law incorporates an external document merely by
reference. So, if NIST tries again to modify the US Code in this
fashion, and they succeed, then the ITU will lose their copyright over
the content of TF.460 within the United States. Any citizen of the US
will not be liable for reproducing it.
Given that the colloquium in Torino made it relatively clear that UTC
is universal time, not atomic time, all I can say to that notions is:
Go for it NIST!
What if, however, the notion of getting the standard for civil time
into an openly available publication might be the tacit underlying
reason for starting this whole process of re-evaluating UTC in
broadcast time signals? Could it in effect be that some of the folks
at USNO and/or NIST actually wished to wrestle the standard away from
the ITU in order to remedy some of the problems caused by its
proprietary nature?
--
Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064
sla_at_ucolick.org Voice: +1 831 459 3046 http://www.ucolick.org/~sla
PGP: 1024/E46978C5 F6 78 D1 10 62 94 8F 2E 49 89 0E FE 26 B4 14 93
Received on Tue Jul 29 2003 - 22:19:24 PDT