Bogus results from NMEA/WNRO tangle

[Hal Murray]

> I handle the regressions in gpsd so no need to fix them up.  They have always
> had a line: 

Good. But that doesn't get the refclock drivers in ntpd.  I've been discussing 
refclock_nmea.

> So that is two roll overs, so far..

Right.  But only one pivot date.


>> Things like WNRO fixup can be done by adding 1024*7*86400.
>> There is no need for any calendar conversions.
> That is not a calendar conversion? 

There is no year/month/day.  The code I fixed was using struct calendar from 
ntp_calendar.h


>> The refclocks need to convert things like YYYY-MM-DD to seconds.
>> POSIX should provide that, but doesn't.  See next chunk.
> POSIX mktime() does that. 

mktime uses the local time zone.  We need UTC.


> Lost me.  Isn't that why gpsd does everything in time_t?  Doesn't ntpd do the
> same? 

The context is converting GPS HH-MM-SS without YYYY-MM-DD to a time_t.

So we assume the system time is close to right, get the time_t for the start 
of today and add on the seconds-this-day from GPS.

The case that needs a 1 day fixup is when system time is 23:00:00 and GPS says 
01:00:00.  The time_t for start-of-today from the system clock needs to be 
bumped forward by a day.

I said not tested.  You said happens every day.  But it doesn't happen at day 
roll over if you only sample every second when GPS provides a sentence and the 
system time is close to GPS time.  They will both be in the same second and 
hence same day.

Each of the refclocks is slightly different.  The final result is that they 
need the offset between the refclock sample and the system time.  Some of the 
code uses struct calendar and code in ntp_calendar. I'm trying to eliminate 
that.


-- 
These are my opinions.  I hate spam.