Brooks Harris wrote: >On 2014-11-04 04:59 PM, Zefram wrote: >>(Contrary to Brooks's earlier statement, the table does not >>imply anything about pre-1972 UTC.) >I don't understand why you say that. Can you explain what you mean? >It seems to me the origins of both PTP and NTP are certainly >"pre-1972 UTC".
The PTP epoch is not defined by UTC. Expressing the PTP epoch in UTC, as is done in clause 7.2.2, does require specific knowledge of pre-1972 UTC, and clause 7.2.2 thus clearly implies that pre-1972 UTC is the rubber-seconds system described by tai-utc.dat. But table B.1 doesn't express the PTP epoch in UTC. The NTP epoch is notionally in UTC, but as previously noted the historical leap schedule doesn't affect current NTP<->UTC conversions. The NTP system thus doesn't imply any particular leap schedule. It is agnostic on pre-1972 UTC behaviour, in fact to the extent that it's no problem at all that the NTP epoch precedes by decades not only all forms of UTC but even atomic clocks. Table B.1 doesn't attempt to express the NTP epoch in TAI, or do anything else that would break this agnosticism. Table B.1 doesn't give any specific conversions between NTP and PTP scalar values, nor between those and UTC or TAI. In particular, it doesn't give any conversion for the NTP epoch. So no implied UTC leap schedule here. What it does give is a pair of complementary conversion formulae, amounting to PTP_scalar = NTP_scalar - 2208988800 + currentUtcOffset This allows us to compute specific conversions for any time for which all these terms are well defined. The critical part is that "currentUtcOffset", which refers to the difference (TAI-UTC)/s. In order to perform a conversion, you have to supply the correct DTAI value yourself; the conversion formulae do not tell you the DTAI value. In order to be able to perform a conversion, there has to be a well-defined DTAI value; the conversion formulae do not imply that there always is one. The formulae thus do not imply any specific leap schedule, nor any specific extent of UTC. >From 1972 onwards, DTAI is uncontroversial. From 1961 to 1971, it is possible to use the conversion formula with the rubber-seconds UTC, with the understanding that currentUtcOffset will usually be fractional (as it is in the time_t example in section B.2). However, it's rather silly to perform a conversion for that era, because neither PTP nor NTP existed back then, and both protocols by nature only process current timestamps. Prior to 1961, DTAI is undefined because UTC is undefined, so it is not possible to perform a PTP<->NTP conversion with respect to real UTC. If you decide to instead use a fictitious version of UTC and TAI for pre-1972 times, you may have a well-defined fictitious DTAI as far back as you like. This may match rubber-seconds UTC over its era or differ from it; it may have whatever leap schedule and frequency shifts you like. Under such a system, you can use the same conversion formula to perform well-defined, but entirely fictitious, PTP<->NTP conversions. As with conversions using the real rubber seconds, this is silly due to the protocols not having been in use at the time. The conversion formulae in table B.1 don't tell you the UTC leap schedule. They're a framework that makes use of whatever leap schedule you choose to feed into them. -zefram _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs