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