[LEAPSECS] the big artillery
brooks at edlmax.com
Tue Nov 4 18:16:52 EST 2014
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
Have a look at 18.104.22.168 General, 22.214.171.124
timePropertiesDS.currentUtcOffset, 126.96.36.199 timePropertiesDS.leap59,
188.8.131.52 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.
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
More information about the LEAPSECS