devel@ntpsec.org said:
> No? Well, I just did. Fsck...me...sideways! It's true. The reason all
> those old, busted Y2K-afflicted refclocks worked is that ntpd really does
> ignore the year part of clock timestamps.
The problem I'm interested in is not Y2K, it's GPS rollover. 1024 weeks is
Hal wrote:
>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 fr
> 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
Question directed particularly to Hal and Daniel:
I have been working on a document that Hal Murray requested, a
comprehensive discussion of rollover effects in Unix, NTP, and
GPSD calendars. Writing this has required me to read the refclock
code looking for how it copes with these.
There is a m
