[LEAPSECS] the big artillery

[Zefram]

I wrote:
>It sounds as though Annex B may contain actual errors, in such things
>as the interpretation of POSIX time_t.  Good job it's not normative.

I've now seen the actual text of Annex B (thanks to an unattributable
benefactor).  Here is my review of it.  Overall it's mostly correct,
but poorly drafted.

Part of the text risks some confusion between TAI and TT, by referring
to the SI second "defining the TAI timescale".  However, the distinction
is preserved in another part of the text which describes TAI as "based
on the SI second as realized on the rotating geoid".  Clearly the
authors are aware of the distinction between the theoretical ideal
and the practical realisation, but by omitting explicit description,
and textually linking the SI second directly to TAI, they risk readers
failing to appreciate this.

The text introducing UTC immediately jumps into describing ISO 8601
syntax.  This gives a misleading impression that ISO 8601 is especially
tied to UTC.  There is a part of ISO 8601 that specifically refers to
UTC, namely the zone offset syntax, but that part of the syntax isn't
mentioned here.  ISO 8601 ought to be discussed separately from the
specific time scales.

The description of UTC does attempt to cover both eras, but isn't entirely
accurate for the rubber-seconds era.  The initial description, applicable
to both eras, says that UTC and TAI differ by "a constant offset
... modified on occasion".  The use of "constant" is dubious, because
anything that gets modified is clearly not constant.  Anyway, it appears
to refer to the offset being piecewise constant.  In the leap-seconds
era the offset does have this behaviour, but in the rubber-seconds era
the frequency shifts mean that the offset changes continuously.

The statement that "UTC experiences a discontinuity" at leap seconds is
misleading.  The concept of discontinuity applies to scalar quantities,
but not to a broken-down UTC time.

The description of leap-seconds UTC is correct as far as it goes.
The mention of "integral second correction", although correct, conflates
two issues that would be better explicated separately: UTC only leaping
by integral seconds, and the TAI-UTC offset being integral seconds.
The description then incongruously jumps to noting that UTC and TAI
can both have timestamps broken down into the traditional components.
As with the ISO 8601 syntax, that's a more generic point that should have
been discussed separately from the specific details of the time scales.

The description of rubber-seconds UTC correctly notes the TAI-UTC offset
changing "in fractions of a second", but entirely fails to mention the
frequency shifts.

The mention of POSIX jumps to ISO 8601, just as the introduction of
UTC did.  It is again incongruous.  There's a sentence about applying
"the POSIX algorithm" to a PTP scalar value, which says essentially
what I described as my interpretation of the note on the definition of
the PTP epoch.  It says it more clearly than that note, but still not
brilliantly.  It refers to ISO 8601 again, using the ISO 8601 textual
representation as a proxy for a broken-down time.

There's some essentially correct discussion of using the count of
accumulated leap seconds as an offset to convert between a PTP scalar
value and a POSIX time_t value.  It's described in a slightly roundabout
way, never bringing out the time_t value as an interesting product, and
again going via textual representations.  There is some justification
for this (not discussed in the text): the PTP-derived time_t values are
more strictly tied to UTC than are wild time_t values.

There is a worked example of time_t conversion, but it's rather
misleading, because it's in the rubber-seconds era, pretty much at the
POSIX epoch.  The example correctly describes the "currentUtcOffset"
value used in the computation being near 8 and non-integral.  The protocol
can't actually transmit a non-integer value for this parameter, but of
course it never needs to, because it never transmits pre-1972 timestamps.
It's also an era for which wild time_t values are not at all tied to UTC.
So the example is correct, but involves complications that would never be
encountered in practice.  The example should have used a modern timestamp,
probably from 2006.

The time_t example has a trivial error in using ":" instead of "-"
as the separator for the elements in an ISO 8601 date representation.

The descriptions of acquiring TAI and UTC time from NTP and GPS are
essentially correct.  The statement that "NTP does not correct ... [at
leap seconds]" is unclear: its intended interpretation implies that the
clocks behind NTP naturally tick UTC time and would have to be adjusted
to count TAI seconds, but actually the reverse is closer to the truth.
The subsequent sentence clarifies satisfactorily.

The table of conversion expressions between PTP, NTP, and GPS times
is correct.  The PTP<->NTP conversion includes a correction for leap
seconds, and the PTP<->GPS conversion does not; both of these are as they
should be.  (Contrary to Brooks's earlier statement, the table does not
imply anything about pre-1972 UTC.)

-zefram