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);
    }