✘leapsecond.py

[Gary E. Miller]

Yo All!

I have been tracking down more GPS week rollover issues.  Strangely the
Trimble Lassen iQ sometimes outputs full weeks, and sometimes truncated
weeks, in the same second!.  An annoying receiver to be sure...

That led me to leapsecond.py in the gpsd source top directory.  It
seems to think the current leap second is 19, not 18.

According to:
        http://www.leapsecond.com/java/gpsclock.htm

        GPS - UTC = 18.

Yet from autogenerated timebase.h:

#define BUILD_CENTURY   2000
#define BUILD_WEEK      29                   # Assumes 10-bit week counter
#define BUILD_LEAPSECONDS       19
#define BUILD_ROLLOVERS 2         # Assumes 10-bit week counter

Anyone have an idea what is going wrong here?

I only see two of those ever used:

timebase.c:    context->leap_seconds = BUILD_LEAPSECONDS;
timebase.c:    context->century = BUILD_CENTURY;

This breaks reproduceable builds and some of the regressions every time
the leap second changes.  OTOH it works around a lot of receivers that
never report the current leap second.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgpDL7OgeapvZ.pgp
Description: OpenPGP digital signature