imp at bsdimp.com
Fri Dec 31 14:06:44 EST 2010
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
More information about the LEAPSECS