Refactor NMEA0183 century handling.

No logic changes. All regression tests pass.

The real point here is to get all the code for time-related edge cases
into timebase.c so it can be reviewed as a unit.

1 files changed, 1 insertions, 22 deletions

diff --git a/driver_nmea0183.c b/driver_nmea0183.c
index e81bad40..50f826d5 100644
--- a/driver_nmea0183.c
+++ b/driver_nmea0183.c
@@ -767,28 +767,7 @@ static gps_mask_t processGPZDA(int c UNUSED, char *field[],
 	    gpsd_report(session->context->debug, LOG_WARN,
 			"malformed ZDA day: %s\n",  field[2]);
 	} else {
-	    session->context->valid |= CENTURY_VALID;
-	    if (century > session->context->century) {
-		/*
-		 * This mismatch is almost certainly not due to a GPS week
-		 * rollover, because that would throw the ZDA report backward
-		 * into the last rollover period instead of forward.  Almost
-		 * certainly it means that a century mark has passed while
-		 * gpsd was running, and we should trust the new ZDA year.
-		 */
-		gpsd_report(session->context->debug, LOG_WARN,
-			    "century rollover detected.\n");
-		session->context->century = century;
-	    } else if (session->context->start_time >= GPS_EPOCH && century < session->context->century) {
-		/*
-		 * This looks like a GPS week-counter rollover.
-		 */
-		gpsd_report(session->context->debug, LOG_WARN, 
-			    "ZDA year %d less than clock year, "
-			    "probable GPS week rollover lossage\n",
-			    year);
-		session->context->valid &=~ CENTURY_VALID;
-	    }
+	    gpsd_century_update(session, century);
 	    session->driver.nmea.date.tm_year = year - 1900;
 	    session->driver.nmea.date.tm_mon = mon - 1;
 	    session->driver.nmea.date.tm_mday = mday;