[LEAPSECS] the big artillery

[Brooks Harris]

On 2014-11-04 04:59 PM, Zefram wrote:
> 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.
Thats a quick study of a deep document. You may be seeing how some feel 
its confusing.

Have a look at 8.2.4.1 General, 8.2.4.2 
timePropertiesDS.currentUtcOffset, 8.2.4.4 timePropertiesDS.leap59, 
8.2.4.5 timePropertiesDS.leap61, and related.

>
> 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.
Right. And as I said, its in this way PTP is sometimes implemented.

> (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". Both have counting mecanisms before 1972, and both have 
implications for how post-1972 UTC (the Leap Second era) may need to be 
calculated, depending on your implementation design.

-Brooks

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