On 12/30/2010 17:23, Paul Sheer wrote:
To take only 10 years to decide about something that is going to affect us in 600 years time is absurd considering the small number of people on both sides of the debate.
I think that talking about time lines that are 10x longer than we've had UTC may be over reaching. 600 years from now, we'll be well past the December/June leap-second paradigm we enjoy today.
[[ don't read in the following unconditional support for the eliminate leaps entirely scenario, but rather it shows issues with how we're doing it today, and why some change needs to happen ]]
If we are looking really long term, then we need to have a frank discussion on how to cope with the exponentially increasing need for leap seconds. Sometime around 2100 we'll have more than two a year (the projections range from 2058 to 2211 depending on the actual long-term rate of change of the length of day). Sometime around 2500 we'll need more than 4 per year.
So 600 years out is likely a stretch. There will need to be changes significantly before then. There's much software that assumes that leap seconds happen in December or June. That code will need to change in the next hundred years to cope with leap seconds happening in the alternate dates. Most code I've seen gets the alternate dates wrong, either by ignoring the possibility, or by assuming that if you get a 'leap indicator' in august, there is necessarily a leap second in September. While one could say the standard hasn't been followed, that 'non-conformance' is endemic in many systems that assume Dec/Jun times, so other systems that rely on them need to make that assumption. GPS' use of an exact time helps a lot, but critical infrastructure pieces, from OS support to ntpd, hard-wire these assumptions, and would need to have a top-to-bottom reevaluation to cope with different dates.
Sometime in the next 500 years, we'll need to figure out how to do leap seconds more than 4x a year. Similar issues would need to be addressed here as well. But given the rate of change of technology since 1972 and extrapolating into the future, it is really hard to predict what the issues here might be. I have operational experience with gear that implements the current convention (subset of the standard), but little with gear that would be developed to cope with the shift...
Against that backdrop, the current 'announce it 6 months in advance' paradigm clearly is a loser. More leaps would mean more notice is required. An algorithmic approach for periods of decades or more would likely be the only viable approach: moving from an observational calender that it is to day, to align more with the length of year adjustments that we do with leap days. We accept that we can be over a day off in our calendar, and nothing bad has happened as a result, since it all averages out over the long term. If we are going to continue to align UT and UTC, something similar is necessary as the frequency of leaps increase.
Warner _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
