[LEAPSECS] Future Leap Seconds

[Warner Losh]

> On Jan 26, 2015, at 11:58 PM, Hal Murray <hmurray at megapathdsl.net> wrote:
> 
> 
>> If Bulletin C contained a table of leap seconds for the next 6*N (for
>> hopefully large values of N), a significant hassle to leap second
>> implementation could be avoided as 6*N would approach the useful life of an
>> embedded system for relatively small values of N and the embedded system
>> wouldn?t have to guess based on incomplete or contradictory information like
>> it does today (especially if this system isn?t connected to the internet).
> ...
> 
> I don't understand this case.  Can somebody give me an example of a system 
> that needs accurate time and isn't connected to a place where it can get leap 
> info?
> 
> The simple example would be a clock, say with a nice display.  But clocks 
> drift, so it would need a way to track the current time.  That means it is 
> "connected" to something like WWVB or GPS, and they both provide leap-pending 
> announcements.

A “cold spare” that’s sitting on the shelf powered off for more than 6 months. When
the original fails, the hot spare is returned to service and must wait an additional ~30
minutes to get the latest almanac before it can recover UTC time from GPS time.
This 30 minutes of down time puts the system at < 4 9’s of reliability, and is an
unacceptable delay. With a pre-computed table of leaps for several years, this
delay could be avoided, and the system can return to service much faster. GPS
time can be recovered in < 1 minute (and sometimes faster if you know your lat/lon
a priori), so the potential savings here is rather large.

Sure, you could power these units up from time to time to have them get the latest
leap info, but that takes man power, time, planning, coordination as well. All that
cost and bother would be eliminated with a table spanning several years.

Warner