[LEAPSECS] Longer horizon

[Warner Losh]

On Jul 9, 2012, at 1:58 PM, Hal Murray wrote:


> 

>> (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. 

> 

> I don't understand this area.

> 

> How often do systems need to get updated to track time zone changes?  Maybe 

> tracking leap second announcements every 6 months would help scheduling 

> updates.


The ones that run on UTC? Never.


> Has the US Congress stopped playing with DST rules?  When was the last change 

> in Indiana?


When running UTC-based systems?  These don't matter.


> How often do things change in the EU or the rest of the world?

> 

> Or are we talking about systems that don't use time zones?  If so, what sorts 

> of things do they do?  How big is the problem space at the intersection of 

> time matters but updating a table is hard?



There's two issues here.  First, the current "right" database can't be updated in place: you have to restart.  Second, there's the cold spare situation where you have a complete redundant copy of the hardware to swap in when the primary copy fails.  Since this is a cold spare, sitting on a shelf, bringing them up every so often to get the latest leap second information can be difficult, especially if the only place that the plug into is where the primary lives...  Cold systems can stay cold much longer if the time horizon for leap seconds is expanded from 6 months.

Warner