[LEAPSECS] The Debate over UTC and Leap Seconds

[Rob Seaman]

Poul-Henning and Warner are each willing to entertain the option of improving the mechanism for scheduling leap seconds:

On Aug 10, 2010, at 1:22 PM, Poul-Henning Kamp wrote:


> There is a 3rd but nobody seems willing to take it seriously:

> 

> 	"Make leap seconds at lot less painfull by announcing them

> 	10 years in advance".   That makes them "calendar" instead

> 	of "timekeeping" for the software people, and moves the

> 	update problem from real-time networking requirements to a

> 	software distribution issue.  20 years would be better, but

> 	10 years is livable.


On Aug 10, 2010, at 1:18 PM, M. Warner Losh wrote:


> The fact remains that the infrequent and erratic nature of leap

> seconds makes them difficult to test for (end to end).  Eliminating

> them solves the problem.  Scheduling them out N years helps a lot

> since the tables can be placed in the software now, and time and

> materials can be planned out more than 6 months in advance so there's

> no 'mid year surprises' in somebody's budget for extra QA, GPS

> simulator time, etc.


And I'm certainly willing to entertain such an option.  In fact, no change whatsoever is required to the current UTC standard to permit this to happen.  We could simply start improving the scheduling logistics.  Is 10 years possible?  Got me, but much more than 6 months is clearly possible.  Perhaps the DUT1 constraint will need to be relaxed in some fashion.  But while we are incessantly spinning our wheels trying to swat away the ITU proposal we are kept from being able to debate the pros and cons of DUT1 constraints.

It is precisely the ITU that is rejecting this option, along with the vast space of other options that preserve civil time as a flavor of mean solar time.

This is not a two-way discussion.  This is not a zero-sum game.  Long term real world concerns (the Earth rotates and tides slow it down) can be combined with near-term computer industry concerns.

Rob