[LEAPSECS] My FOSDEM slides

Zefram zefram at fysh.org
Thu Mar 5 13:29:57 EST 2015


Brooks Harris wrote:
>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.

It's correct to the microsecond precision given.  My only real correctness
concern there is that it implies an exact equivalence which there isn't.
However, it is somewhat misleading by virtue of failing to explicate that
it is using the rubber-seconds UTC which is otherwise irrelevant to PTP.

>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
...
>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

No, there is no contradiction there.  The table makes no claim about
the correspondence between TAI and UTC at any particular point in time.
It makes correct claims about the correspondences between various scalar
representations of time.  The only subtlety is the "currentUtcOffset" term
in the PTP<->NTP equations.  The currentUtcOffset (meaning (TAI-UTC)/s)
is not defined for all points in time, and during the rubber-seconds
era of UTC it takes on non-integral values.  This obviously can be a bit
confusing, because for the purposes of PTP as an operational protocol,
in which context only current timestamps are relevant, currentUtcOffset
is always well-defined and integral.  For the purposes of table B.1 it
is not.

>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

I don't think you've succeeded in defining a particular time scale here.
Your previous messages, and the table and comments later in your present
message, suggest that you're thinking of a time scale that amounts to TAI
- 10 s prior to 1972.  But the phrases "Gregorian calendar timescale"
and "treats the measurement unit as integral seconds" don't seem to
actually imply that.  I can't make much sense of either phrase.

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

Your focus on epochs is unhealthy.  Some of the epochs don't unambiguously
correspond to particular points in time, and in context that's not
a problem.  Notice that table B.1 that you quoted doesn't make any
reference to epochs per se: it doesn't describe relationships between
epochs, it describes relationships between *scalar values*.  What matters
is that these scalar values correspond to specific points in time over the
time period that matters for the application.  Scalar value zero isn't
inherently part of the relevant time period.  Taking NTP in particular,
no one was running NTP in 1900, so it is of no significance that NTP
zero doesn't correspond to a specific point in time.

-zefram


More information about the LEAPSECS mailing list