[ I'm posting this unsent email now that Warner independently proposed the same thing! ]
In that is the nugget of how leap seconds are no different announcements that the daylight/summer time zones transition will happen at some date other than the previous schedule. (e.g., due to some sports event like the 2000 Olypmics and the 2006 Commonwealth Games in Australia, or any of the other excuses that bureaucrats have used when they say you'll have to update your zoneinfo files.)
Even if this were true, I think we can give them a break for Y2K and expect it not to happen too many more times. So here's an idea to test the waters slowly -- To see which or if any applications run into trouble when DUT1 exceeds 0.9 second -- how about if IERS stretches it very slowly... Over the past 4 decades the recommended tolerance for DUT1 has gone from 0.1 s to 0.5 to 0.7 to 0.9 seconds. Why not continue this trend over the next decade or two? Delay the next leap second by 6 or 12 months and push just over the 1.0 edge and see if the water is too hot for some piece of gear. If so, it can probably be fixed. And given how much DUT1 varies day by day, the failure will not be a hard failure; it will be intermittent. Plenty of time to fix it before the next leap second brings DUT1 back under 1.0. Leap seconds would still occur, but this would provide an orderly slow triage of equipment or software that needs attention. Instead of the emotional, political, and technical uncertainty of removing leap seconds altogether, just aim for the very simple goal of |DUT1| < 2.0 seconds. A small step instead of a giant leap... /tvb _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
