> On Jan 26, 2015, at 3:03 PM, Tim Shepard <[email protected]> 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 _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
