[LEAPSECS] Time math libraries, UTC to TAI

Fri Dec 30 12:56:19 EST 2016

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<sla at 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 at leapsecond.com
>> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>>
>>
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at 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