[LEAPSECS] My FOSDEM slides

Thu Mar 5 12:23:26 EST 2015

On 2015-03-05 08:39 AM, Martin Burnicki wrote:
> Tony Finch wrote:
>> Martin Burnicki <martin.burnicki at meinberg.de> wrote:
>>>
>>> I agree, but as I've tried to point out above I think a better 
>>> project design
>>> would have been to use TAI instead of GPS time. PTP works natively 
>>> with TAI,
>>> and you can easily convert between he two scales.
>>
>> I don't understand this paragraph. The three timescales you mention have
>> totally different formats:
>>
>> TAI: YYYY-MM-DD T HH:MM:SS
>> PTP: SSSSSSSSSS
>> GPS: WWWW SSSSSS
>>
>> They have different epochs:
>>
>> TAI: 1958-01-01 T 00:00:00 Z
>> PTP: 1970-01-01 T 00:00:00 Z
>> GPS: 1980-01-06 T 00:00:00 Z
>>
>> So I don't see how it makes sense to argue that PTP is more like TAI 
>> than
>> GPS time.
>
> In the strict scientific sense I agree.
>
> However, in practice, and for "current" dates, you can convert each of 
> them to a number of seconds since the epoch, and for practical 
> purposes the difference is just an integral number of seconds.
I agree.

We have seen the casual term "TAI-like", meaning an "uninterrupted 
incrementing count of seconds" from some epoch. PTP and GPS are 
"TAI-like" in that sense.
>
> For example, the IEEE Std 1588-2008 says:
>
> "The PTP epoch is 1 January 1970 00:00:00 TAI, which is 31 December 
> 1969 23:59:51.999918 UTC"
>
> However, the time stamps used in the PTP packets are just binary 
> numbers of seconds, and you have to apply an integral number of 
> seconds to convert this to UTC.

Yes, that's how it must be treated.

I urge caution interpreting the meaning of the PTP Epoch as stated in 
the spec.

The first part of that sentence is correct "The PTP epoch is 1 January 
1970 00:00:00 TAI". But the  second part, "which is 31 December 1969 
23:59:51.999918 UTC", is not, or, is at least very misleading.

This of course begs the all questions regarding a "proleptic UTC" 
timescale. What, exactly, is that? Did it exist before 
1972-01-01T00:00:00Z (UTC)? Does it include the "rubber-band era" 
between approximately 1961 and 1972?

The spec goes through long explanations of the relation of its epoch to 
the "POSIX algorithm". It wanders through explanation of the 
"rubber-band" era, and how the "broken down time" results are obtained 
from gmtime(). This is all wicked confusing. Apparently the IEEE PTP 
committee took "UTC" to include the "rubber-band era", and so attempted 
to reconcile the PTP epoch to it.

In an *informative* Annex B - Timescales and epochs in PTP, there is 
further (confusing) explanation, but then comes Table B.1?Relationships 
between timescales. There we find -

Table B.1?Relationships between timescales
>From                  | To          |  Formula
NTP Seconds           | PTP Seconds | PTP Seconds = NTP Seconds ? 2 208 
988 800 + currentUtcOffset
PTP Seconds           | NTP Seconds | NTP Seconds = PTP Seconds + 2 208 
988 800 ? currentUtcOffset
GPS Seconds =         |             |
(GPS Weeks            |             |
× 7 × 86 400)         |             |
+ GPSSecondsInLastWeek|             |
(GPS week number must |             |
include 1024 × number |             |
of rollovers)         | PTP Seconds | PTP Seconds = GPS Seconds + 315 
964 819
PTP Seconds           | GPS Seconds | GPS Seconds = PTP Seconds ? 315 
964 819

All the values in this table are *integral seconds* and they are correct 
with respect to the definitions other timescale Epochs. (They neglect to 
say the values for NTP are to NTP's "prime epoch of era 0", a subtle but 
important point)

These are the values you must use for a practical implementation of PTP, 
and that is the convention adopted by the PTP community. These values 
*contradict* the second part of the epoch specification sentence 
("...which is 31 December 1969 23:59:51.999918 UTC") and all the rest of 
the PTP epoch explanations throughout the document.

The "rubber-band era", while historically important, is just not 
relevant to practical timekeeping applications concerned with modern UTC 
and "civil time". The scattered nature of the UTC specifications lead 
from UTU-R Rec 460 to BIPM Annual Report on Time Activities Tables 1 and 
2 that list the historical values of the "rubber-band era". This leads 
to attempting to figure out what the historical values of UTC were 
during this period. Its interesting, but its a huge distraction until 
you realize it doesn't matter for most purposes. Like many of us, the 
IEEE PTP committee fell into this trap.

You can construct a Gregorian calendar timescale that is proleptic to 
1972-01-01T00:00:00Z (UTC) = 1972-01-01T00:00:10Z (TAI) (note the 10s 
TAI/UTC offset) and treats the measurement unit as integral seconds. 
This is, I believe, is the timescale most often used to calculate 
offsets between timescales, but is never explicitly acknowledged or 
named. Here I'll name it "Gregorian proleptic to UTC1972".

With that you can reconcile the offsets between the epochs of NTP, TAI, 
PTP, POSIX, UTC, and GPS in integral seconds.

-----------------------------------------------------------------------------------------
Origin      |  UTC1972    | Coincides   |          UTC |Leap|        TAI
Name        |  Seconds    | with        | |Secs|
             |  Offset     | Origin of   |                   ( Earth  )
             |             |             | (Correction)
             |             |             | |    |
-----------------------------------------------------------------------------------------
UTC1900     | -2272060800 | NTP         | 1900-01-01T00:00:00Z | 10 | 
1900-01-01 00:00:10
TAI1958     |  -441763210 | TAI         | 1957-12-31T23:59:50Z | 10 | 
1958-01-01 00:00:00
TAI1970     |   -63072010 | 1588/PTP    | 1969-12-31T23:59:50Z | 10 | 
1970-01-01 00:00:00
UTC1970     |   -63072000 | POSIX       | 1970-01-01T00:00:00Z | 10 | 
1970-01-01 00:00:10
TAI1972     |         -10 | UTC + 10s   | 1971-12-31T23:59:50Z | 10 | 
1972-01-01 00:00:00
UTC1972     |           0 | UTC         | 1972-01-01T00:00:00Z | 10 | 
1972-01-01 00:00:10
UTC1972_7_1 |   +15724800 | First Leap  | 1972-07-01T00:00:00Z | 11 | 
1972-07-01 00:00:11
UTC1980_1_6 |  +252892800 | GPS Epoch   | 1980-01-06T00:00:00Z | 19 | 
1980-01-06 00:00:19

On this timescale, for practical implementations, the PTP Epoch, 
1970-01-01T00:00:00 (TAI) aligns with 1969-12-31T23:59:50 (Gregorian 
proleptic to UTC1972), *not* 31 December 1969 23:59:51.999918 UTC.

-Brooks

>
> Similarly, the comments in the NIST leap second file say:
>
> #    The second column shows the number of seconds that
> #    must be added to UTC to compute TAI for any timestamp
> #    at or after that epoch.
>
> Even though the number of seconds between TAI and GPS timestamps is 
> constant, if you use all the scales TAI/GPS/UTC in an application you 
> have to do more different conversions than if you had only TAI and UTC.
>
> Just imagine a PTP grandmaster, controlled by a GPS receiver which 
> outputs raw GPS time.
>
> Tony, I'm sure you know all of the above, but I just wrote this to 
> make clear what I meant.
>
> Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20150305/c31f9770/attachment.html>