[LEAPSECS] the big artillery

[Zefram]

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