[LEAPSECS] BBC radio Crowd Science

[Tom Van Baak]

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