[LEAPSECS] it's WP7A week in Geneva

[Tom Van Baak]

> when all is said and done).  A 12.5 minute down time means your annual

> reliability can only be 4 9's, not 5 9's...  This is why many

> receivers remember the last UTC offset values and warm start with them

> if they have only been off a short period of time...

> 

> Warner


Yes, but you know this only partly solves the problem; it might
even make it worse depending on how rigorous your testing
needs to be.

Now you have a battery- or EEPROM-based GPS receiver that
either 1) produces UTC correctly right away, or 2) produces a
UTC that's off by one second right away -- and somewhere in
the next 12.5 minutes later it spontaneously corrects itself and
produces UTC correctly.

User code can usually handle being told by a GPS receiver
that "UTC is not known yet; use GPS time instead". But when
a GPS receiver says "sorry, by the way, all the UTC time stamps
I've sent you in the past quarter hour were off by one second",
that might be a little more trouble to deal with.

The receiver has to define what a "short time" is or perhaps
more accurately, when in time that short time is. For example,
caching the leap second offset will be fine if that short time is
in October but not if it's near the end of December. Caching
all of dTls, dTlsf, WNt, WNlsf might take care of that. But then
you also have to consider 256-week issues:
http://www.leapsecond.com/notes/leapsec256.htm

/tvb