[LEAPSECS] the big artillery

[Zefram]

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

The actual historical relationship between TAI and UTC prior to 1972
is defined by the well-known tai-utc.dat file.  1970-01-01 falls within
the rubber-seconds era of UTC, and the file gives the expression

	TAI-UTC=   4.2131700 S + (MJD - 39126.) X 0.002592 S

Applying this, we find that 1970-01-01T00:00:00 TAI was approximately
1969-12-31T23:59:51.9999 UTC.  The fractional part of the seconds value is
exactly 99991827/100000003 (which can't be expressed in ISO 8601 syntax).
That's the PTP epoch expressed in the actual historical UTC; no other
value is correct.  POSIX is irrelevant to this, and ISO 8601 merely
provides the syntax to describe the approximate result.

>                                               the term "UTC" may or
>may not be applicable to date-time before 1972

Many things referring to "UTC" only address the leap-seconds era, and
so don't apply pre-1972.  The PTP spec's conversion of its epoch to UTC
is one of the relatively rare cases of actually engaging with pre-1972
UTC and using it correctly.  So in this case the term does apply.

Although I applaud the correctness, the PTP spec actually wins very
little by including the UTC conversion.  As previously discussed in the
context of your CCT proposal, PTP never actually processes timestamps
anywhere near its origin: it suffices to define the relationship between
PTP scalar values and TAI only for current times.  Defining the epoch
as 1970-01-01T00:00:00 TAI is in itself a neat way of defining the
relationship, but the conversion to UTC is much less neat.

Presumably the intent of the conversion was to clarify the specification
of the epoch.  For me it succeeds in that, because I recognise the two
expressions as describing almost the same time (within a microsecond),
and this clarifies that where the spec says "TAI" it really means it.
However, by sowing the confusion into which you have fallen, it seems
that the clarification is counterproductive for readers not familiar
with rubber-seconds UTC.

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

That's a ridiculous conclusion.  Integral-second alignment between
the PTP timescale (effectively TAI) and UTC, for the pre-1972 era, is
irrelevant, because no one actually used PTP in that era.  It's also
impossible to achieve with the real UTC, both because UTC and TAI had
a frequency offset in that era (so a UTC second isn't an integral TAI
second) and because of the irregular leap at the end of 1971 (so that
there weren't an integral number of UTC seconds between second-aligned
UTC times -- it's not aligned with *itself*).

Your "treating it as" a second-aligned UTC time amounts to inventing a
fictitious proleptic leap-seconds UTC.  It's not wrong to invent such
a beast, but it is wrong to call it "UTC" without qualification, as you
did earlier in this thread (and as you also did in the initial version
of your CCT proposal).  You should always explicate when you're using
such a non-standard time scale.

Furthermore, you've invented a proleptic leap-seconds UTC *badly*.  That 2
s difference between your proleptic UTC and the real UTC illustrates
that yours is tracking UT1 poorly.  This happens because (as with the
CCT proposal) you've supposed that there are no leap seconds in the
proleptic era.  If you're going to have a proleptic leap-seconds UTC,
you need to schedule some proleptic leap seconds to maintain tracking.
For example, Tony Finch's proleptic leap-seconds UTC (pUTC, extending
back to 1958-01-01) has leaps at 1971-06-30 and 1970-06-30, so the PTP
epoch is exactly 1969-12-31T23:59:52 pUTC.  You do get integral-seconds
alignment between TAI and pUTC.

So, in summary, your pseudo-UTC is pointless, misrepresented, and
defective.

-zefram