[LEAPSECS] BBC radio Crowd Science

[Zefram]

Nice analysis, thanks.

You've looked only at the situation where the user only wants to recover
the time corresponding to the timestamp that was transmitted by the clock.
Very often a user also wants to be able to project ahead a bit, displaying
times that come some known duration after the transmitted timestamp.
Perhaps the user wants to handle interruptions in access to the upstream
clock, or apply a correction for transmission delays, or is a clock
trying to synchronise to the upstream clock.

If the user wants TAI, the results are the same as what you showed.
But if the user wants UTC, then they need to know the near-future shape
of UTC: they need to know what leaps are coming up.  This is not an
instantaneous parameter of the timestamp being supplied by the clock,
in the way that DTAI can be.  It's a subset of the information that
you referred to as the leap second table.  It therefore doesn't need
to be disseminated on a real-time basis like the clock's timestamps.
It may be obtained out of band, but it is handy if the clock supplies
this kind of information in addition to its real-time timestamps.

GPS's arrangement amounts to supplying TAI in real time, and more slowly
two DTAI values and a cutover time.  This is sufficient not only to
recover instantaneous UTC but also to project UTC over the immediate
future.

I'd really like to see time signals send a complete leap second table,
covering at least the period from the inception of that time signal
format, up to as far ahead as IERS has publicly decided.  The table can
be chopped up into small fragments which get interspersed with other
clock metadata.  Each fragment can be as semantically simple as "for UTC
month YYYY-MM, DTAI = NN s".  Each Bulletin C would have the effect of
adding new fragments to the repertoire.  Listening to the signal for
long enough, starting at an arbitrary time, should be sufficient for
the listener to acquire the complete table.

-zefram