Century correction absent in some refclocks
hmurray at megapathdsl.net
Tue Aug 29 19:26:58 UTC 2017
> What I don't understand is why the refclocks returning only 2-digit years
> ever worked at all. Does the sample-processing code simply ignore the
> century part of the year? If so, why is nmea supplying that?
Here is a comment in refclock_process_f
* Compute the timecode timestamp from the days, hours, minutes,
* seconds and milliseconds/microseconds of the timecode. Use
* clocktime() for the aggregate seconds and the msec/usec for
* the fraction, when present. Note that this code relies on the
* filesystem time for the years and does not use the years of
* the timecode.
That doesn't sound right, but I haven't started pulling that string.
Converting 2 digit year to 4 digit should be simple: just add 2000. We don't
need to pivot since we are only interested in the current time which can't be
in the late 1900s, Things would be more interesting if we had old log files
running through test decks.
YEAR_BREAK and YEAR_PIVOT are defined in ntp.h
The comments indicate that things are mixed up with tm_year
I haven't pulled that string either.
This may be mixed up with the mysterious GPS rollover fixup I haven't found
These are my opinions. I hate spam.
More information about the devel