[LEAPSECS] Future Leap Seconds

[Warner Losh]

> On Jan 27, 2015, at 8:47 PM, Tim Shepard <shep at alum.mit.edu> 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.
> 
> 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.

Because it does. Why is this even questioned.

It has to set the time on the atomic clocks to UTC.

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

Because it is the base time for the LORAN transmitters? It’s at the top
of the food chain.

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

Because the contract said that all logging must be in UTC, even early
logging, and the LEDs on the front panel of the atomic clock must be
set to UTC. These items were non-negotiable.

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

Because it is the timing source for the LORAN-C transmitter, and the
spec says you have to be within 10ns.

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

You’d think that, but you’d be wrong. It’s a lot less brittle than you think.

It’s *VERY*HARD* to restart the pulse trains if you figure out later that
your notion of UTC was wrong. And you have to do it before you can
start transmitting, or you’re broadcasting the wrong positions.

But rather than carp at why the system wasn’t designed in a way that
you think is correct, learn from this that UTC with leap seconds can
present very real problems because it tends to be specified top
to bottom.

Warner