Devuan bug report logs - #314
gpsd: ..2'nd roll over bug: gpsd "clock is 56 years wrong", like "1963-07-18T08:57:40.584Z"

Package: gpsd; Reported by: Arnt Karlsen <arnt@iaksess.no>; dated Sun, 7 Apr 2019 21:33:01 UTC; Maintainer for gpsd is (unknown).


Message received at 314@bugs.devuan.org:


Received: (at 314) by bugs.devuan.org; 7 Apr 2019 22:00:02 +0000
Date: Sun, 7 Apr 2019 23:53:43 +0200
From: Arnt Karlsen <arnt@iaksess.no>
To: 314@bugs.devuan.org
Subject: Re: bug#314: Acknowledgement (gpsd: ..2'nd roll over bug: gpsd


..upstream bug reports:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926615
https://savannah.nongnu.org/bugs/index.php?56094

..our bug report:
https://bugs.devuan.org//cgi/bugreport.cgi?bug=314

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.


Acknowledgement sent to Arnt Karlsen <arnt@iaksess.no>:
Extra info received and forwarded to list. Copy sent to owner@bugs.devuan.org. Full text available.


Information forwarded to devuan-bugs@lists.dyne.org, owner@bugs.devuan.org:
bug#314; Package gpsd. Full text available.


Message received at submit@bugs.devuan.org:


Received: (at submit) by bugs.devuan.org; 7 Apr 2019 21:30:06 +0000
Date: Sun, 7 Apr 2019 22:57:58 +0200
From: Arnt Karlsen <arnt@iaksess.no>
To: Devuan Bug Tracking System <submit@bugs.devuan.org>, Debian Bug Tracking
Subject: gpsd: ..2'nd roll over bug: gpsd "clock is 56 years wrong", like

Package: gpsd
Version: 3.16-4
Severity: important

..upstream bug.  




Hi,


..reportbug reports our (Devuan) BTS is down, bug report on gpsd: 
Content-Type
: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Arnt <arnt@iaksess.no>
To: Devuan Bug Tracking System <submit@bugs.devuan.org>
Subject: gpsd: ..2'nd roll over bug: gpsd clock is 56 years wrong,
"1963-07-18T08:57:40.584Z" Message-ID:
<155465156363.24771.3526445890355259661.reportbug@sda3> X-Mailer:
reportbug 7.1.6+devuan2.1 Date: Sun, 07 Apr 2019 17:39:23 +0200
X-Debbugs-Cc: arnt@iaksess.no

Package: gpsd
Version: 3.16-4
Severity: important

..upstream bug.  


Dear Maintainer,

*** Reporter, please consider answering these questions, where
appropriate ***

   * What led up to the situation?

..according to http://catb.org/gpsd/NMEA.html#_dates_and_times : 
GPS date and time are subject to a rollover problem in the 10-bit 
week number counter, which will re-zero every 1024 weeks (roughly 
every 19.6 years). The last rollover (and the first since GPS went 
live in 1980) was in Aug-1999; the next will fall in Apr-2019. 


..checks out rather well:
arnt@sda3:~$ date --date='1024 weeks ago'
Sun Aug 22 18:23:04 CEST 1999
arnt@sda3:~$ date --date='2048 weeks ago'
Sun Jan  6 17:23:36 CET 1980
arnt@sda3:~$ date --date='TZ=UTC 2048 weeks ago'
date: invalid date ‘TZ=UTC 2048 weeks ago’
arnt@sda3:~$ date --date='TZ="UTC" 2048 weeks ago'
Sun Jan  6 19:25:50 CET 1980
arnt@sda3:~$
http://www.leapsecond.com/java/gpsclock.htm
http://www.leapsecond.com/java/cal.htm


..fix suggestions: hard code third 10bit era and/or move to 
the new 13bit "CNAV" data format pointed to above. 

..this patch hard codes third 10bit era as suggested in 
gpsd-3.1x's timebase.c:
arnt@nb6:~$ diff -u timebase.h-3.16 timebase.h-new
--- timebase.h-3.16     2016-01-08 20:30:27.000000000 +0100
+++ timebase.h-new      2019-04-07 20:11:52.903644739 +0200
@@ -1,9 +1,9 @@
 /*
  * Constants used for GPS time detection and rollover correction.
  *
- * Correct for week beginning 2016-01-07T00:00:00
+ * Correct for week beginning 2019-04-07T02:00:00 UTC
  */
 #define BUILD_CENTURY  2000
-#define BUILD_WEEK     854            # Assumes 10-bit week counter 
-#define BUILD_LEAPSECONDS      17
-#define BUILD_ROLLOVERS        1      # Assumes 10-bit week counter
+#define BUILD_WEEK     1              # Assumes 10-bit week counter 
+#define BUILD_LEAPSECONDS      19
+#define BUILD_ROLLOVERS        2      # Assumes 10-bit week counter


..and ditto for gpsd-3.17:
arnt@nb6:~$ diff -u timebase.h-3.17 timebase.h-new
--- timebase.h-3.17     2017-09-07 13:53:40.000000000 +0200
+++ timebase.h-new      2019-04-07 20:11:52.903644739 +0200
@@ -1,9 +1,9 @@
 /*
  * Constants used for GPS time detection and rollover correction.
  *
- * Correct for week beginning 2017-09-07T00:00:00
+ * Correct for week beginning 2019-04-07T02:00:00 UTC
  */
 #define BUILD_CENTURY  2000
-#define BUILD_WEEK     941           # Assumes 10-bit week counter 
+#define BUILD_WEEK     1             # Assumes 10-bit week counter 
#define BUILD_LEAPSECONDS      19
-#define BUILD_ROLLOVERS        1         # Assumes 10-bit week counter
+#define BUILD_ROLLOVERS        2         # Assumes 10-bit week counter



..this patch hard codes third 10bit era as suggested in 
gpsd-3.11's timebase.c: 
arnt@sda3:~$ diff -u timebase.h*
--- timebase.h-3.11  2019-04-07 19:19:42.442197516 +0200
+++ timebase.h-ny      2019-04-07 19:18:28.572535352 +0200
@@ -1,8 +1,8 @@
 /*
  * Constants used for GPS time detection and rollover correction.
  *
- * Correct for week beginning 2014-08-21T00:00:00
+ * Correct for week beginning 2019-04-07T00:00:00
  */
-#define CENTURY_BASE   201400
-#define LEAPSECOND_NOW 16
-#define GPS_WEEK_NOW   1806
+#define CENTURY_BASE   201900
+#define LEAPSECOND_NOW 19
+#define GPS_WEEK_NOW   2049


..current timebase.h in gpsd-3.11 source:
arnt@sda3:~$ cat timebase.h
/*
 * Constants used for GPS time detection and rollover correction.
 *
 * Correct for week beginning 2014-08-21T00:00:00
 */
#define CENTURY_BASE    201400
#define LEAPSECOND_NOW  16
#define GPS_WEEK_NOW    1806
arnt@sda3:~$




   * What exactly did you do (or not do) that was effective (or
     ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Distributor ID: Devuan
Description:    Devuan GNU/Linux 2.0 (ascii)
Release:        2.0
Codename:       ascii

Architecture: armv6l

Kernel: Linux 4.19.32+
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot
set LC_ALL to default locale: No such file or directory UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gpsd depends on:
ii  adduser              3.115
ii  init-system-helpers  1.48+devuan2.0
ii  libbluetooth3        5.43-2+deb9u1
ii  libc6                2.24-11+deb9u4
ii  libdbus-1-3          1.10.22-1+devuan2
ii  libgps22             3.16-4
ii  libusb-1.0-0         2:1.0.21-1
ii  lsb-base             4.1+devuan2
ii  netbase              5.4

Versions of packages gpsd recommends:
ii  python  2.7.13-2
pn  udev    <none>

Versions of packages gpsd suggests:
ii  dbus          1.10.22-1+devuan2
ii  gpsd-clients  3.16-4

-- debconf information:


-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.


Acknowledgement sent to Arnt Karlsen <arnt@iaksess.no>:
New bug report received and forwarded. Copy sent to owner@bugs.devuan.org.

Your message specified a Severity: in the pseudo-header, but the severity value important was not recognised. The default severity normal is being used instead. The recognised values are: critical, grave, normal, minor, wishlist.

Full text available.


Report forwarded to devuan-bugs@lists.dyne.org, owner@bugs.devuan.org:
bug#314; Package gpsd. Full text available.


Devuan BTS -- Powered by Debian bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.

Devuan Bugs Owner <owner@bugs.devuan.org>.
Last modified: Fri, 15 Nov 2019 21:39:01 UTC