NOT "unintentional"
-S
On 2016-12-30 11:37, Brooks Harris wrote:
On 2016-12-28 04:16 PM, Steve Allen wrote:
On Wed 2016-12-28T16:00:17 -0500, Brooks Harris hath writ:
I don't think so. This is POSIX so-called "1970-01-01 00:00:00 UTC"
not 1588/PTP. 1588/PTP epoch is 10s earlier.
At 1970-01-01 the difference TAI - UTC(BIH) was 8.000082 SI seconds.
I trust you're calculations, and your stating it as "TAI-UTC(BIH)"
makes it clear its not UTC(NIST) or some other UTC, and that's good.
But, as you point out below, ".. all of this is pedantic and moot for
any currently operational system because it was not operational then".
The "rubber band era", the period of development of TAI and UTC from
approximately 1960 to 1971 which led to the crucial TAI-to-UTC
calibration point of 1972-01-01 00:00:10 (TAI) = 1972-01-01 00:00:00
(UTC), may be seen as an interesting but obsolete history which is
now irrelevant to consideration of practical timekeeping.
I've been in many discussions of this issue and struggled with it
myself. If you engage the UTC specifications starting with ITU-R Rec
460 and attempt to understand the origins and TAI-UTC values you may
first find -
BIPM Annual Report on Time Activities
(http://www.bipm.org/en/bipm/tai/annual-report.html)
Table 1. Relative frequency offsets and step adjustments of UTC...
Table 2. Relationship between TAI and UTC...
Those tables list the frequency and non-integral seconds adjustments
prior to 1972. This leads one to believe these values are relevant to
understanding and implementing UTC. But the documentation is complex
and unclear, leading to further research to discover or confirm your
understanding.
There is a hole in the data of these tables; Rec 460 tells us the
origin of TAI is "1 January 1958" but the first TAI-UTC value listed
in the tables is in 1961 - what happened between 1958 and 1961? What
does "1 January 1958" mean; 1958-01-01 00:00:00 (TAI) or 1958-01-01
00:00:00 (UTC)? Wait, did UTC exist in 1958? Why 1958? Eventually you
might discover that "1 January 1958" was put in place retroactively in
1971 (Rec 460 actually tells us so, but the history of it in the
literature is convoluted). OK, but what is the TAI-UTC offset at
1958-01-01? Turns out, obscurely, zero. Hmmm. The TAI-UTC offset is
exactly 10 seconds at TAI1972 = UTC1972. So how, exactly, should we
distribute the TAI-UTC values across that 1958-to1972 period? And if
the atomic time frequency itself was being changed how should we
reconcile this with a system that has a stable frequency?
Many of us have been led down this path, and we've probably found
Steve's excellent and extensive documentation about timescales.
In the end the only sensible thing to do is ignore these obsolete
facts and establish a proleptic integral-second timescale. That's
exactly what NTP does, and many POSIX-based systems. The TAI-UTC
values published by IERS, such as
(https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat), show
no TAI-UTC values prior to TAI1972 = UTC1972.
Yet the idea that a timescale must honor these historical facts
persists. I've come to see this whole topic of pre-1972 TAI-UTC values
as a trap, a trip down a rabbit hole.
The first version of IEEE 1588 was not entirely consistent with its
text and appendix information, so it was not clear whether that time
scale was supposed to be TAI or TAI - 10.
The second version of IEEE 1588 clarified that the intent is TAI.
I've been involved in lengthy discussions about the PTP "epoch", and
this has been entangled with the difficulties of defining the
TAI-to-UTC relationship prior to 1972.
[By the way, IEEE 1588 defines "epoch" as "3.1.9 epoch: The origin of
a timescale.". This is arguably, perhaps subtlety, not the same as the
definition of the POSIX "the epoch", which is intentionally vague The
term "epoch" does not appear in ISO 8601 or any IEC documents I've
found. Caution with the term "epoch".]
1588 states "7.2.2 Epoch - The PTP epoch is 1 January 1970 00:00:00
TAI, which is 31 December 1969 23:59:51.999918 UTC.". (This is
consistent with Steve's statement above - "At 1970-01-01 the
difference TAI - UTC(BIH) was 8.000082 SI seconds."). However, this
seems in conflict with Annex B, Table B.1 - Relationships between
timescales, one entry of which says "NTP Seconds = PTP Seconds + 2 208
988 800 - currentUtcOffset".
It seems from long discussions that typical implementations of PTP use
an integral second relationship between TAI and UTC, as per the
(non-normative) Annex Table B. If date-time before 1972 UTC is treated
as integral seconds the same way NTP and POSIX define their origins
the PTP epoch is 1970-01-01 00:00:00 (TAI) = 1969-12-31T23:59:50
(UTC). This is more more consistent with NTP and the typical, or at
least some, interpretation of POSIX "the epoch".
This is the interpretation used in the new SMPTE (Society of Motion
Pictures and Television Engineers) ST 2059-2 and ST 2059-1 standards
for synchronization over network systems. It is based on IEEE
1588/PTP. It states:
---------------
6 SMPTE Epoch and Signal Alignment
The SMPTE Epoch shall be 1970-01-01T00:00:00TAI, which is the same as
the PTP Epoch specified in IEEE
Standard 1588-2008.
Note: The SMPTE Epoch is 63072010 seconds before 1972-01-01T00:00:00Z
(UTC).
---------------
In SMPTE standards parlance the first sentence is normative, but the
"Note" is informative. The intention of the note is to inform
implementers that the intention for SMPTE purposes is to interpret the
"PTP Epoch" as integral seconds before 1972-01-01T00:00:00Z (UTC).
Unfortunately, and probably unintentionally, the text leaves some
ambiguity because the IEEE 1588/PTP states - "... which is 31 December
1969 23:59:51.999918 UTC" while the SMPTE "note" says, and the
intention is it be, 1969-12-31T23:59:50 (UTC).
Having been a prime instigator of that note, it was very deliberate and
not unintentional. It says nothing about UTC prior to 1972. It makes
clear the relationship between TAI and UTC at 1972-01-01T00:00:00 (UTC)
so that the reader is not misled by the ambiguity prior to that date
that might be caused by statements in IEEE 1588-2008.
-S
Having been involved in these discussions I know the intention is the
latter. The words in a standard matter.
One thing for sure - if we can't agree what a particular timescale's
origin, or "epoch", means and its exact relationship to 1972-01-01
00:00:10 (TAI) = 1972-01-01T00:00:00 (UTC) and we don't implement them
consistently, there won't be interoperability no matter how exacting
all the other details of the counting schemes may be.
-Brooks
The choice of TAI - 10 would put the origin of the time scale at the
intersection of the grey vertical line and the green horizontal line
seen in the second plot on
http://www.ucolick.org/~sla/leapsecs/amsci.html
And for any system using that time scale that puts the origin at
1.999918 SI seconds after the (BIH average of the) radio broadcast
time signals said it was 1970-01-01T00:00:00.
But all of this is pedantic and moot for any currently operational
system because it was not operational then. Only a few things like
astrometry of solar system bodies and spindown of a handful of pulsars
have data and models with enough precision to discern this.
Everything and everyone else can reasonably assert that they do not
have to care and that every day has always had 86400 seconds of
duration equal to what they are currently ticking.
--
Steve Allen<s...@ucolick.org> WGS-84 (GPS)
UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat
+36.99855
1156 High Street Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
