[LEAPSECS] [QUAR] Bulletin C and all that
brooks at edlmax.com
Mon Jan 26 15:05:55 EST 2015
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
"The name "Coordinated Universal Time (UTC)" was approved by a
resolution of IAU Commissions 4 and 31 at the 13th General Assembly in
"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 -
"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.
> How about "leap_second_epoch" or if the term epoch is undesirable "leap_seconds_origin" labelled as "leap00"
> 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.
>>> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the LEAPSECS