[LEAPSECS] the big artillery

Brooks Harris brooks at edlmax.com
Mon Nov 3 13:11:25 EST 2014

Hi Micheal,

On 2014-11-03 02:43 AM, michael.deckers via LEAPSECS wrote:
> On 2014-10-31 17:39, Brooks Harris wrote:
>> Yes. Its primary timescale, sometimes called "PTP Time", more 
>> properly the "PTP
>> Timescale", is a "TAI-like" counter (uninterrupted incrementing count of
>> seconds). Note its origin, or epoch, is 1969-12-31T23:59:50Z, ten 
>> seconds before
>> the POSIX "the Epoch" (if you take that to mean two years (2 x 365 x 
>> 86400)
>> seconds before 1972-01-01T00:00:00Z (UTC), as NTP does).
> Just nitpicking:
> In [IEC 61588 of 2009-02. section 7.2.2] we read:
> "The PTP epoch is 1 January 1970 00:00:00 TAI,
> which is 31 December 1969 23:59:51.999918 UTC."
> So you are off by about 2 s.

CAUTION about the PTP Epoch. Its not "just nitpicking".

I have been involved with a standards body attempting to use 1588/PTP. 
There was a (long!) debate about what the PTP Epoch actually is. This 
discussion included several participants with experience using 1588/PTP. 
The conclusion is that the PTP Epoch is 1970-01-01T00:00:00 (TAI) which 
*must be treated as* 1969-12-31T23:59:50Z (UTC), *not* "1969 
23:59:51.999918 UTC" as stated in the 1588/PTP document. The reason is 
to maintain an integral-second alignment between the PTP Timescale and 
the UTC timescale.

The relationship between the PTP timescale, POSIX, and UTC are discussed 
in some detail in the document. Unfortunately it is confusing, 
misleading, and arguably wrong.

Quoting [IEEE Std 1588™-2008, IEEE Standard for a Precision Clock 
Synchronization Protocol for Networked Measurement and Control Systems]

7.2 PTP timescale, 7.2.1 General - "The timescale PTP: In normal 
operation, the epoch is the PTP epoch and the timescale is continuous; 
see 7.2.4. The unit of measure of time is the SI second as realized on 
the rotating geoid."

This describes a "TAI-like" timescale - an uninterrupted incrementing 
count of seconds, and specifically " the SI second as realized on the 
rotating geoid.". That is the primary counting mechanism, appropriate to 
the main objective as stated in the title - "for Networked Measurement 
and Control Systems".

7.2.2 Epoch states "The PTP epoch is 1 January 1970 00:00:00 TAI, which 
is 31 December 1969 23:59:51.999918 UTC."

Here we wade into the debate and confusion produced by the historical 
TAI/UTC relationship before 1972. In the same section, we read -

"NOTE 1— The PTP epoch coincides with the epoch of the common Portable 
Operating System Interface (POSIX) algorithms for converting elapsed 
seconds since the epoch to the ISO 8601:2004 printed representation of 
time of day; see ISO/IEC 9945:2003 [B16] and ISO 8601:2004 [B17]."

Here we wade into the debate and confusion about POSIX's "The Epoch". In 
the same section, we also read -

"NOTE 2— See Annex B for information on converting between common 

In "Annex B (informative) Timescales and epochs in PTP" we find a long, 
detailed, discussion of timescales, especially PTP, TAI, POSIX, and UTC, 
and character representation via 8601. Note the entire annex is 

The discussion attempts to resolve the question about what the TAI/UTC 
relationship was *before* 1972-01-01T00:00:00Z and how this is related 
to POSIX and represented by 8601. Of course, as often discussed and 
debated on this [LEAPSECS] list, the term "UTC" may or may not be 
applicable to date-time before 1972 and what portions of the historical 
record might be interpreted as "proleptic" and exactly what that means. 
One could argue the entire section is very confusing.

At the end of Annex B we find a table - Table B.1 - Relationships 
between timescales. Note the values of the relationships amongst the 
timescales in this table are all *integral second* values. This seems to 
be in contradiction to much of the discussion in Annex B and to the 
statement of the PTP Epoch in paragraph "7.2.2 Epoch".

If we parse that sentence (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.") 
carefully, the first part, "1 January 1970 00:00:00 TAI" is clear 
enough, but exactly what to make of "31 December 1969 23:59:51.999918 
UTC"? That value might be correct depending on how you interpret the 
historical record of TAI/UTC offsets and exactly what you mean by some 
"proleptic UTC timescale".

We've been advised by PTP experts that A) yes, its confusing, and B) 
most implementations use a integral-second interpretation, as in Table 
B.1. I understand the "escape clause" they use to justify this is the 
"(POSIX) algorithms" phrase in Note 1 of 7.2.2 Epoch. By "(POSIX) 
algorithms" they mean "gmtime()" and (strict) POSIX "ticks" at 1Hz, so, 
integral seconds. In any event its really the only interpretation that 
yields a manageable, practical, implementation that is consistent with 
TAI and UTC, NTP, and common-use of POSIX.

However, while its said "most" implementations follow this approach, it 
doesn't mean every one does. I fear there are already implementations of 
1588/PTP that do not match each other in this crucial respect.


> Michael Deckers.
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs

More information about the LEAPSECS mailing list