Here's a different take on the situation. Or maybe it's just how someone with cesium clocks looks at the problem. Don't over think what I mean by "clock", "user" and leap second "table" below.
Timescale / timestamp conversion in Six Easy Cases: 1) clock sends UTC, user wants UTC - N.B. clock needs table in order to maintain UTC. 2) clock sends UTC, user wants TAI - N.B. clock needs table in order to maintain UTC. - User needs table and utc_to_tai() conversion. 3) clock sends UTC and +N, user wants TAI - N.B. clock needs table in order to maintain UTC. - User does not need table. - User does radix-60 math on UTC timestamp + N to get TAI timestamp. - Clock is careful to send the right N near negative and positive leap seconds. 4) clock sends TAI, user wants TAI - N.B. neither clock nor user needs table. 5) clock sends TAI, user wants UTC - N.B. clock does not need table. - User needs table and tai_to_utc() conversion. 6) clock sends TAI and -N, user wants UTC - N.B. clock needs table in order to maintain N. - 6x) User finds that TAI and N is *insufficient* to generate UTC timestamp (in the case of a positive leap second). - Therefore user needs table as in case 5 above -- and essentially ignores N, or - 6a) clock must send N1 and N2 so that user can generate UTC in all cases, or - 6b) clock must send N and F (e.g., positive leap flag) so user can generate UTC correctly, or - 6c) clock must send N and R (e.g., radix 60 or 61) so user can generate UTC correctly. ---------- How does this relate to our discussion? We often see "equations" like: TAI = UTC + (TAI-UTC) or UTC = TAI + (UTC-TAI) and it's not clear if it's a succinct statement about time scale offset or a recipe for time stamp conversion. We'd like to think they are exactly equivalent, as one finds in mathematical equations (but they are not equations). The former expression, TAI = UTC + (TAI-UTC), looks very much like case 3 above, where N = TAI-UTC. There's no problem with case 3. N is clean and simple: 36 in 2016 (including the leap) and 37 in 2017. The latter expression, UTC = TAI + (UTC-TAI), is unfortunately more like case 6 above, where N = UTC-TAU. And since case 6x is useless, one must actually implement case 6a or 6b or 6c instead: If you stick with case 6x, you will encounter contradictions and may resort to blaming the wording of Bulletin C (several). If you do a table lookup and peek ahead and behind to get N1 and N2, then it's like case 6a (Steve). If you do a table lookup and find the timestamp is a leap second and flag it, then it's like case 6b (Brooks). If you do a table lookup and call your leap second flag a variable radix, then it's like case 6c (Warner). /tvb _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
