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 [EMAIL PROTECTED] 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