[LEAPSECS] Bulletin C and all that

[Warner Losh]

> On Jan 26, 2015, at 3:03 PM, Tim Shepard <shep at alum.mit.edu> wrote:
> 
> 
> 
>> While you're at it, make sure the words June and December are also never written into the standard. Only IERS gets to pick the month, and everyone one else follows what they tell us. That goes for code, tables, scripts, standards, man pages, etc. We can assume with near-term modest earth rotation rate offsets that IERS will pick June and December, but as the offset grows then March and September, and then other 8 months are fair game as well. So if you want a standard to be robust, please avoid any hard-coded reference to "preferred" months. Note that the current "6 month" advance warning is also not set in stone so no one standard should ever depend on that either.
>> 
> 
> And also we might someday get more than one leap second scheduled in
> the same Bulletin C.  For example, maybe someday a bulletin C might be
> issued that says "no leap second at the end of June, there will be a
> leap second a the end of September, there will be a leap second at the
> end of December, no leap second at the end of March, and there will be
> a leap second at then end of *next* June.'  Maybe something like all
> that in the same bulletin C.  And maybe the next bulletin C shortly
> after the beginning of June would reiterate the schedule through next
> June and also announce what will happen at the end of September.
> (This is all speculation, but it would be nice if code that is written
> this year and deployed later doesn't become broken if changes like
> that happen some day.)

If Bulletin C contained a table of leap seconds for the next 6*N (for hopefully
large values of N), a significant hassle to leap second implementation could be
avoided as 6*N would approach the useful life of an embedded system for
relatively small values of N and the embedded system wouldn’t have to guess
based on incomplete or contradictory information like it does today (especially
if this system isn’t connected to the internet). Granted, it can usually guess
fairly well, especially if a GPS receiver is involved, but having something set
in stone would mean not having to update tables in flash which is inherently
less reliable than using read-only tables from flash.

Warner