[LEAPSECS] Skepticism

[Warner Losh]

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