[LEAPSECS] Future Leap Seconds

[Tim Shepard]

> >> 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.

Why does such a system need to know what time it is UTC?   It seems to
me if knowing what time it is UTC matters, then it must be in
communication of some sort with something, otherwise why would the UTC
time matter?   And if it is in communication with something else, why
not just fetch a table of recent leap seconds that way.

And if it is not in communication with something else, then why would
it need to know what time it is in UTC?   Why isn't GPS time good
enough for whatever it is that it needs time for?

And even if it is in communication with something else, why not just 
use GPS time?   Why must it "recover UTC time from GPS time"?    Why
does it need UTC time?

And even if it needs UTC time, why does it need it to be so accurate?


It seems to me a robust system would need methods of recovering from
erroneous situations where some component's notion of the time was off
by a few seconds (if not tens or hundreds of seconds).  If some
important system cannot handle a leap second without disruption, then
perhaps we should be worried about what else it can not handle, or how
brittle the system is to begin with.

			-Tim Shepard
			 shep at alum.mit.edu