[LEAPSECS] Bulletin C and all that

Zefram zefram at fysh.org
Tue Feb 10 09:08:11 EST 2015


Rob Seaman wrote:
>            leap26.leapsec.com  ->  250.10.36.152   -> OK 2015  7  36  1  (1, 0)
...
>               c48.leapsec.com  ->  242.4.35.72     -> OK 2015  1  35  0  (0, 0)

I think it's a mistake to encode Bulletin C per se, or even to concentrate
on leap events.  What clients need to know is the relationship between
UTC and TAI, which (post-1972) takes the form of a piecewise constant
difference.  What should be encoded is that difference, for each monthly
piece.  A client can be expected to know which months it is interested in.

Encoding Bulletin C is especially problematic because your encoding
necessarily makes some fairly strong assumptions about the scope of
each bulletin, assumptions which are not inherent features of UTC but
merely epiphenomena of how UTC is currently administered.  There is no
inherent requirement that Bulletin C be issued at particular intervals,
or that there be a one-to-one correspondence between bulletins and
leap opportunities (even when only considering June and December to
be opportunities).  Bulletin C's real significance is to announce some
previously-unknown monthly pieces of the definition of UTC, and there's
no inherent need for those pieces to have any particular relationship.
Once they've been announced, there's no inherent persistent grouping
between the offset segments that happened to be announced at the same
time.

-zefram


More information about the LEAPSECS mailing list