[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
- ✘leapsecond.py, Gary E. Miller, 2019/11/01
- Re: ✘leapsecond.py,
Bernd Zeimetz <=