[LEAPSECS] [QUAR] Bulletin C and all that

[Brooks Harris]

On 2015-01-25 03:03 PM, Stephen Scott wrote:
> Since UTC is defined by the IERS before 1972-01-01 "beginning_of_utc" is not appropriate.
> This is the beginning of integer leap seconds, not UTC.

As a practical matter of modern timekeeping the UTC timescale started at 
1972-01-01T00:00:00Z (UTC). NTP, POSIX, 1588/PTP and others refer to 
epochs and timescales they call "UTC" that occur earlier than 
1972-01-01, so this confuses matters. But those epochs exist on 
"Gregorian calendar timescale that is proleptic to the UTC origin", not 
on the modern UTC timescale proper. We've got to get past this confusion.

The problems start with the fractured nature of the standards defining 
UTC. Rec 460 points you first to the BIPM where we find the BIPM Annual 
Report on Time Activities and in it Table 1, Relative frequency offsets 
and step adjustments of UTC and Table 2 - Relationship between TAI and 
UTC. These retain the frequency and fractional second adjustments made 
to TAI/UTC during the development of the technology, as they should for 
the historical record. But this sends engineers into a Alice in 
Wonderland evaluation of that "rubber-band" period. This turns out to be 
an irreverent quagmire, a serious distraction to the task at hand.

The effort seems relevant because people try to reconcile proper UTC 
with the NTP and POSIX timescales. Only after long study and debate does 
one come to recognize the facts. Many people and organizations have 
fallen into this trap.

Its amazing to me that since the 1970s the confusion remains, and that 
no official documents have been produced that clarify the situation. In 
particular, the fact that the "UTC timescale started at 
1972-01-01T00:00:00Z (UTC)" is not stated officially anywhere I'm aware 
of - you have to assemble that fact from many sources and there are many 
subtleties you have to discover for yourself. It would be a major 
contribution if such a definition was agreed upon somewhere by somebody.

Maybe Rob Seaman's DNS efforts and naming the components of its Leap 
Seconds table presents an opportunity to take a stab at it? Its more 
than just a name - you need to define the UTC timescale, its parts, and 
finally how these are represented in the data of the format. I applaud 
the effort to build an example of automating the metadata distribution. 
I hope it will eventually include a specification that might be a model 
for an officially standardized version somewhere.

By the way, to be pedantic about the history of the UTC name, as is the 
tradition here at LEAPSECS -

Metrologia, 2001, 38, The leap second: its history and possible future
http://www.cl.cam.ac.uk/~mgk25/time/metrologia-leapsecond.pdf

"The name "Coordinated Universal Time (UTC)" was approved by a 
resolution of IAU Commissions 4 and 31 at the 13th General Assembly in 
1967 [85]."

"The International Earth Rotation Service (IERS) was established in 1987 
by the IAU and the IUGG and began operation on 1 January 1988."

Steve Allen's Time Scales page points out -

Time Scales
http://www.ucolick.org/~sla/leapsecs/timescales.html

"Nothing resembling the name UTC was used prior to 1960, so any claim 
that UTC can be used before then is inappropriate. The name UTC did not 
appear in any official context until 1974, so any claim that UTC was 
used prior to 1974 is almost certainly a reinterpretation of history 
which does not correspond to anything in contemporary documents."

The history is tangled, but none of it matters except to historians.


-Brooks


> How about "leap_second_epoch" or if the term epoch is undesirable "leap_seconds_origin" labelled as "leap00"
>
> Stephen*
> *
> On 2015-01-25 13:11, Rob Seaman wrote:
>> Makes sense (and the danger of list processing).  If no further correction I'll shift all the leapNN names to start from June 1972.  Are we all agreed that it is correct to say that the beginning of UTC is 1972-01-01T00:00:00Z with TAI-UTC 10s at that moment?  If so, I'll introduce another name with the same value as the current leap01 but called something like "beginning_of_utc" or some such.
>>
>> Thanks!
>>
>> Rob
>> --
>>
>>> On Jan 25, 2015, at 10:00 AM, Michael Deckers via LEAPSECS<leapsecs at leapsecond.com>  wrote:
>>>
>>>
>>>   On 2015-01-25 14:58, Rob Seaman wrote:
>>>
>>>> Please let me know about typos, suggestions, etc.  Needless to say this
>>>>   remains a prototype.
>>> ...
>>>> YYYY MM before  after  encoded crc         IP              Decoded        flags
>>>> ------------------------------------------------------------------------------
>>>> 1972  1      9     10 f8000a00  f5  248.0.10.245    -> OK 1972  1  10  1  (1, 0)
>>>   It would be incorrect to consider the discontinuity of the difference
>>>   TAI - UTC at the epoch when TAI was 1972-01-01T00:00:10 as a leap second;
>>>   the difference increased by about 0.108 s, not by 1 s. Hence, a timestamp
>>>   such as "1971-12-31T23:59:60.2Z" should not be made acceptable.
>>>
>>>   The first leap second occurred when UTC reached 1972-07-01; the information
>>>   about a leap second says something about TAI - UTC both before and after
>>>   the date referenced. At 1972-01-01, however, the information can only say
>>>   something about TAI - UTC for TAI on or after 1972-01-01T00:00:10, but
>>>   nothing (correct) for smaller values of TAI.
>>>
>>>   Michael Deckers.
>> _______________________________________________
>> LEAPSECS mailing list
>> LEAPSECS at leapsecond.com
>> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>>
>
>
>
> ------------------------------------------------------------------------
> <http://www.avast.com/> 	
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <http://www.avast.com/>
>
>
>
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20150126/003e49ef/attachment-0001.html>