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