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 _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
