[LEAPSECS] LEAPSECS Digest, Vol 51, Issue 7

Warner Losh imp at bsdimp.com
Wed Feb 2 18:20:52 EST 2011

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.


More information about the LEAPSECS mailing list