[LEAPSECS] Bulletin C and all that

[Tom Van Baak]

> But there have been real bugs due to leap indicators remaining set too
> long, leading to bogus leaps at the end of July. So in practice there is
> less risk in allowing leaps only in June and December.

Those real bugs are better fixed at their source than worked around in this manner. Ok, easy to say and hard to do, I know.

Perhaps leap indicators should not be booleans but small wrapping integers. For example GPS makes use the low order 8 bits of the week number for almanac version checks. Perhaps the same could be done for leaps, especially if they are encoded as a TAI offset integer instead of +/- yes/no booleans.

Another approach is to stop distributing leap seconds as a monthly flag and instead issue a yearly set of 12 values. That way not only does everyone gets the leap schedule a year in advance but no years or months get special treatment. The TAI-UTC leap second tables simply grow by one line per year.

Also, Rob, et al, did you consider sorting your tables down instead of up? That is, put 1972 at the bottom instead of the top. Most people want to know the current year and not the entire history.

/tvb

> 
> Tony.
> -- 
> f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
> Rockall, Malin, Hebrides, Bailey: Southwest 5 to 7, occasionally gale 8,
> veering west 7 to severe gale 9, perhaps storm 10 in Rockall and Bailey later.
> Very rough becoming high, occasionally very high in Rockall and Bailey later.
> Rain, then squally wintry showers. Moderate or poor, occasionally good.
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs