[LEAPSECS] Automation

[Magnus Danielson]

M. Warner Losh skrev:

> In message: <1230843729.9555.2.camel at glastonbury>

>             Ashley Yakeley <ashley at semantic.org> writes:

> : On Thu, 2009-01-01 at 09:41 -0700, Rob Seaman wrote:

> : > They can't be naively automated.  The schedule is currently  

> : > predictable 6 months in advance.  Nobody has objected to a longer  

> : > schedule; we're positively giddy to give it a try.  NTP is proof of  

> : > concept that automation is possible once the schedule is released.

> : 

> : This might encourage software engineers to do the wrong thing, that is,

> : hard-code a leap-second table.

> 

> But leap seconds are already hard coded, or at least there's a table

> of them, on many systems that need to grok leap seconds.  similar to

> the timezone 'hard coding'.


Rolling back a few messages you find the use of longer schedules. If a 
schedule was given say every 5th year with the upcomming 10 years 
schedule of leap seconds then you have two things, a longer heads-up 
time and a longer valid time. However, such a procedure comes with a 
clear end-date of validity. If you do not update the table prior to that 
you are on your own. Today we have slightly less than 6 months heads-up 
and 6 months of valid-time. For systems requiring hard-coded tables this 
is too short and then it is a hurdle.

For systems having at least some external reference, automatic methods 
such as web or DNS based could be used, with probably the added 
requirement of some means of authenticity checks, could be used to send 
information about upcomming leap-seconds, then the current leap-second 
schedule is more than adequate. Shorter than a month would be possible.
For NTP, root NTP servers could either rely on information sources such 
as GPS or use network based methods to automatically update their own 
list, and then NTP could be used to transfer this knowledge thoughtout 
the network.

As I have understood it, advances in ability to predict earth orbits 
would allow predictions deeper into the future. This would allow for 
longer schedules. It can be argued that maybe "isolated systems" can't 
be that isolated if they require proper UTC representation at the same 
time as they are totally isolated. Never the less, longer schedule times 
seems possible. The implications they would have for such isolated 
systems is slower upgrade rate and to some degree a more stable upgrade 
pattern (every 5 years with my example numbers). The IERS would issue a 
rolling schedule, so their announcement rate would be the same, but 
their predictions would be further out in time than today.

Long schedules and automation can work hand in hand. You can deliver 
long schedules using automatic methods, but the hold-over times would be 
considerably longer.

The drawback of long schedules is that people would forget or ignore the 
issue, with the implied risk of missing or avoiding updates.

Cheers,
Magnus