Fix fencepost errors in GPS epoch (mainly comments).

The definition of GPS_EPOCH in gpsd.h is correct, but the comment
specified the incorrect corresponding date, which is 06-Jan-1980, not
06-Jan-1981, which isn't even a Sunday.

The century hack in driver_nmea0183.c establishes a 100-year window
for interpreting two-digit years.  For now, the range 1980-2079 is
reasonable, given that the GPS epoch is 06-Jan-1980, and the mention
of wrapping "at" 2080 is consistent with this, but the comment
incorrectly placed the GPS epoch in 1981 (perhaps due to believing the
wrong comment in gpsd.h), and the code was written to wrap *after*
2080, rather than *at* 2080.  This would place the window at
1981-2080, which would screw up 1980 (admittedly an unlikely case).

This is mostly about not misleading people reading the code than
actual real-life trouble.

TESTED:
Existing tests pass.  A test case for a year of "80" would be needed
to actually verify the fix, though.

1 files changed, 2 insertions, 2 deletions

diff --git a/driver_nmea0183.c b/driver_nmea0183.c
index 24a0a1b9..0f41a1c8 100644
--- a/driver_nmea0183.c
+++ b/driver_nmea0183.c
@@ -176,9 +176,9 @@ static int merge_ddmmyy(char *ddmmyy, struct gps_device_t *session)
      * Telix fails on GPS rollover to 2099, which 32 bit system
      * can not handle.  So wrap at 2080.  That way 64 bit systems
      * work until 2080, and 2099 gets reported as 1999.
-     * since GPS epoch started in 1981, allows for old NMEA to work.
+     * since GPS epoch started in 1980, allows for old NMEA to work.
      */
-    if (2080 < year) {
+    if (2080 <= year) {
         year -= 100;
     }