GPSD time will jump back 1024 weeks at after week=2180 (23-October-2021)
I just discovered a lurking problem in the timebase.c module in all of the branches for releases >=3.20:
In gpsd_gpstime_resolv():
/* 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 code is going to trigger a 1024 week backward time jump from Saturday October 16, 2021 to Sunday March 3, 2002.
There is similar code in gpsd_gpstime_resolve() that looks like it can be removed:
/* sanity check unix time against leap second.
* Does not work well with regressions because the leap_sconds
* could be from the receiver, or from BUILD_LEAPSECONDS.
* Leap second 18 at 1 Jan 2017: 1483228800
* (long long) for 32-bit systems */
if (17 < session->context->leap_seconds &&
1483228800LL > t.tv_sec) {
long long old_tv_sec = t.tv_sec;
t.tv_sec += 619315200LL; // fast forward 1024 weeks
(void)gmtime_r(&t.tv_sec, &session->nmea.date); // fix NMEA date
(void)timespec_to_iso8601(t, scr, sizeof(scr));
GPSD_LOG(LOG_WARN, &session->context->errout,
"WARNING: WKRO bug: leap second %d inconsistent "
"with %lld, corrected to %lld (%s)\n",
session->context->leap_seconds,
old_tv_sec, (long long)t.tv_sec, scr);
}