[LEAPSECS] Testing computer leap-second handling

Warner Losh imp at bsdimp.com
Mon Jul 9 14:07:43 EDT 2012

On Jul 9, 2012, at 11:56 AM, Steve Allen wrote:

> What we saw at ITU-R in Geneva during January emphasized that

> diplomacy is the art of the possible. The draft presented to the

> assembly

> http://www.itu.int/md/R07-SG07-RP-1005/en

> which we were told has this content

> http://www.ucolick.org/~sla/leapsecs/draftTF460-7.html

> proved not to be possible.


> It is not clear that the linux kernel bugs will change the

> international responses to that draft.


> It is clear that the ITU-R hierarchy really wants WP7A to fix the

> proposal so that it can achieve consensus in time for the 2015

> assembly.


> I suspect that the ITU-R (such as it is possible to attribute

> motivations to such a nebulous bureaucratic entity) would appreciate

> assistance that enables consensus. That is part of the hope behind

> the next futureofutc.org meeting set for next May in Charlottesville.


> Can LEAPSECS contribute ideas for a better draft revision of TF.460 ?

Putting on my computer operational hat, here's my suggestions:

(1) Push for a longer time horizon for leap second announcements. For compute guys, the more lead time the better. 6 months is just too short to meet deployment realities. 5 years would cover most bases, with 10 years covering all but a vanishingly small number. Even 2-3 years would help for two reasons. (1) it would mean only one upgrade during a 5 year deployment rather than possibly 10. (2) It would allow management to plan and budget for extra resources needed to ensure leapseconds will work this time.

(2) Push for a relaxation of DUT1 < 1s so we could reach a 10 year time horizon, or possibly beyond. We know we're going to need ~75 leap seconds over the next hundred years, so why not schedule them like we do leap days now: via a formula that keeps us mostly on track, but allows deviations of up to 2 days from our actual point in the orbit as a short-term error. We could start small by doing things on a decade level and maybe work our way up from there.

Both of these suggestions keep time Universal, they just up the averaging constant or fuzz the approximation without unbounding difference. there's nothing magical about a 1s DUT1: it is just a convenient approximation. People would still get along just fine. Some systems will need to adjust to the new reality, but many won't. Sadly, I know that Steve has some of the kit that would need to change, and they made the choice to go with proprietary, difficult to change system so the cost will be kinda high.


More information about the LEAPSECS mailing list