gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ✘leapsecond.py


From: Bernd Zeimetz
Subject: Re: ✘leapsecond.py
Date: Fri, 1 Nov 2019 23:29:54 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

Hi,

so basically the leapseconds.py code is doing

% wc -l leapseconds.cache
19 leapseconds.cache

so the issue is in the cache generation.

First question:

does ftp://maia.usno.navy.mil work for anybody? Seems dead to me.

looking at the output of leapseconds.py -v -f foo the fix seems to be

diff --git a/leapsecond.py b/leapsecond.py
index b0ef0935d..8acf94dcf 100755
--- a/leapsecond.py
+++ b/leapsecond.py
@@ -229,7 +221,7 @@ def save_leapseconds(outfile):
             line = polystr(line)
             if verbose:
                 sys.stderr.write("%s\n" % line[:-1])
-            if line.startswith(" 1980"):
+            if line.startswith(" 1981"):
                 skip = False
             if skip:
                 continue



But imho the whole thing is a mess as it assumes that there is only one
leapsecond per year and I think that leapseconds.cache file is only used
to count the number of lines.

I *think* the proper fix would be to parse the number of leapseconds
from the bulletin and just use it. No idea why we need to keep a history
of that stuff and count lines while assuming a line means one seconds....


Bernd


On 11/1/19 8:39 PM, Gary E. Miller wrote:
> 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
> 

-- 
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



reply via email to

[Prev in Thread] Current Thread [Next in Thread]