[LEAPSECS] Bulletin C and all that

[Martin Burnicki]

Tom Van Baak wrote:
>> The truncated week numbers are a good source for potential errors
>
> I agree, but...
>
>> If the current week number is off by more than +-127 then this is ambiguous.
>
> No, it's not ambiguous, it was just a Motorola bug. The wrap is in the spec and there's no problem with that. In fact, in 2003 everyone got it right except for one(?) model of Motorola GPS timing receiver. So the spec is fine, GPS is fine, wrapping is fine. But yes, it is a source for errors, and one engineer at Motorola fell for it.

What I mean with "ambiguous" is that you can't even *display* the 
correct leap second date if there has been no leap second for more than 
the number of weeks covered by the 8 bit week number.

For example, IIRC the GPS satellites sent the same 8 bit WNlsf number of 
the last leap date for seven years when no leap second was scheduled for 
that long time, and after some years you had no chance to expand these 8 
bits unambiguously to 10 or more bits to convert this to the real date 
of the last leap second event.

Of course, if you only evaluate WNlsf and DNt if tls and tlsf differ 
(i.e. a leap second is actually scheduled) then everything is fine since 
the numbers have been updated accordingly. Of course this can still fail 
if you evaluate this in a wrong way, which is probably the problem with 
the GPS receivers in fact doing it wrong.

> The only limitation of using an 7- or 8-bit WN field like this is that it prevents GPS from announcing a leap second more than 2.5 or 5 years in advance. That's not much of a limitation.

Or display the correct date of a leap second more than 2.5 or 5 years in 
the past. ;-)


Martin