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 _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
