gpsd/gpsd-week2180.patch
2021-08-11 12:12:57 +02:00

45 lines
1.8 KiB
Diff

Hunk cherry-picked from the following commit. It doesn't add the command to set
the date in tests, i.e. they are broken now.
commit 7f30d88d04dc62b8bd6265ad1d09d72d220f97f6
Author: Gary E. Miller <gem@rellim.com>
Date: Sat Jul 24 20:22:15 2021 -0700
gpsd/timebase.c" Don't compute wrong GPS rollover after 2020-10-23.
gpsfake uses "# Date: yyyy-mm-dd" to set initial time.
Some regressions needed proper dates.
Some regressions now compute proper dates.
diff --git a/gpsd/timebase.c b/gpsd/timebase.c
index 31ac5fab4..513499021 100644
--- a/gpsd/timebase.c
+++ b/gpsd/timebase.c
@@ -388,19 +402,12 @@ timespec_t gpsd_gpstime_resolv(struct gps_device_t *session,
if (week < 1024)
week += session->context->rollovers * 1024;
- /* sanity check week number, GPS epoch, against leap seconds
- * Does not work well with regressions because the leap_sconds
- * could be from the receiver, or from BUILD_LEAPSECONDS. */
- if (0 < session->context->leap_seconds &&
- 19 > session->context->leap_seconds &&
- 2180 < week) {
- /* assume leap second = 19 by 31 Dec 2022
- * so week > 2180 is way in the future, do not allow it */
- week -= 1024;
- GPSD_LOG(LOG_WARN, &session->context->errout,
- "GPS week confusion. Adjusted week %u for leap %d\n",
- week, session->context->leap_seconds);
- }
+ /* This used to sanity check week number, GPS epoch, against leap
+ * seconds. Did not work well with regressions because the leap_sconds
+ * could be from the receiver, or from BUILD_LEAPSECONDS.
+ * Maybe if the regressions files provided BUILD_LEAPSECONDS this
+ * could be tried again.
+ */
// gcc needs the (time_t)week to not overflow. clang got it right.
// if time_t is 32-bits, then still 2038 issues