[LEAPSECS] BBC radio Crowd Science
Tom Van Baak
tvb at LeapSecond.com
Wed Feb 1 17:27:03 EST 2017
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
More information about the LEAPSECS
mailing list