[LEAPSECS] LEAPSECS Digest, Vol 51, Issue 7

[Warner Losh]

On 02/02/2011 12:23, Rob Seaman wrote:

> As Warner implies, an area ripe for consensus-building progress is the "smoothing", i.e., the tolerance for the intercalary adjustments that will continue to be needed (whatever mechanism is implemented and whether or not the ITU has anything to do with the design of the mechanism).  Whatever workflow is being followed to deliver a 5-month lookahead window for leap-seconds could be modified to extend the lookahead very significantly, perhaps by relaxing the DUT1 tolerance by a modest amount.


I'd love to kill leap seconds.  Lots of my problems go away if they are 
just gone.

However, if that isn't possible, I'd be happier with a loser bounds on 
DUT1 that targets <0.5s but can accept up to 2s of drift if the benefit 
from that loser tolerance is a 10 year or longer look ahead horizon.  
That would go a long way towards reducing the pain associated with leap 
seconds since the vast majority of systems have a 10 year or less life 
expectancy, but much longer then 6 months.  While there are exceptions 
to this general rule, those systems can bear the cost of the additional 
complexity they would encounter.

Granted, this only works if at the same time the end-of-month leap 
second rule is reiterated, and if there is a constant commitment to this 
time horizon.  I'm also cool with a decade-long trial period where we 
slowly ramp up from 1/2 year to a year, then two, etc as the earth 
rotation warrants and the horizon of the short-term predictions are 
tested.  In Torin in 2007, for example, there was a presentation that 
said the 500ms threshold of uncertainty was about 2-3 years out.  Also, 
this system only works if there are multiple ways to get the current 
DUT1 for people that need to know and as a fail safe for those systems 
where DUT1 > 1s starts to cause problems.  This should include changes 
to GPS (and other navsats), WWV (and other terrestrial time signals) and 
internet protocols to get this number easily.  Perhaps even an extension 
to ntp and 1588 to allow this information to ride along in those protocols.

Warner