Yo Hal! On Fri, 28 Jan 2022 22:19:15 -0800 Hal Murray <halmur...@sonic.net> wrote:
> > 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.
gpsd does not use a pivot date, Why does anyone need a pivot date?
gpsd just checks if the date fro mthe receiver is less than the
build data and if so, adds 1024 until it is not.
> >> 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
Yet another calendar struct? Why not use the standard one?
Sre looke like a year/month/day:
struct calendar {
uint16_t year; /* year (A.D.) */
uint16_t yearday; /* day of year, 1 = January 1 */
uint8_t month; /* month, 1 = January */
uint8_t monthday; /* day of month */
uint8_t hour; /* hour of day, midnight = 0 */
uint8_t minute; /* minute of hour */
uint8_t second; /* second of minute */
uint8_t weekday; /* 0..7, 0=Sunday */
};
> >> 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.
So use tzset() to change mktime() to use 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.
Which is what mktime() does.
> 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.
Bad assumption. On nstatup a RasPi thinks it is 1969, again.
> 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.
Only if you make the bad assumption above about system time.
> 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.
Please do. That prolly predates the POSIX struct tm.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
pgpeyqJ8ksuJY.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
