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 _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
