Re: [gpsd-dev] gpsd rolls back to 1999

[Greg Troxel]

Hal Murray <address@hidden> writes:

> WNRO is the common term - week number roll over

Thanks.  I think it was W1K back in 1999 when I got new truetime
firmware in a chip packaged with an extractor tool, and we were also
excited about Y2K.  But this is the second time and I already set a
calendar entry for fall or 2038!

>> Some computers boot up with 0 in unix timeval, so we can't assume the
>> system clock is even close.
>
> Is that a problem for GPSD?
>
> It can be a problem for NTS.  The clock has to be close enough so that 
> certificates have valid times.

I'm not sure it's a "problem", but it is absolutely true that we cannot
assume the system clock is close.  That means that we cannot make
decisions about whether anything from the GPSr is right by comparing it
to the current time.  My point is really that the process of
disambiguating/fixing timestamp/datestamp info from the GPSr has to be
independent of the value of the system clock.

Agreed on the certificate validity issue.  There's a further wrinkle
with DNSSEC.  I booted a RPI3 w/o a RTC once that came up 5 days slow
(because it had been off for 5 days and it used the filesystem
superblock time, which is what NetBSD does by default).  It was messed
up because named would not resolve names and ntpd had names not
addresses in ntp.conf.  I added a few servers with IP addr so that next
time it would straighten itself out.  So far gpsd does not seem to need
to resolve DNS names, and I don't think there are any cert validations
in gpsd.  But the time sync and certs chicken/egg problem is difficult.

>From a requirements point of view, we should be able to boot up a system
with an initial clock that is perhaps 1970, perhaps months old, and
perhaps years in the future, and gpsd should run, with a GPSr that may
or may not have WRNO bugs, and it should end up with the correct time.

> I'd expect the recipe to be as follows:
>
> If you have a 2 digit year, add 1900 or 2000.  Pivot around GPS launch year.

For GPS timestamps, it's ok to pivot around the GPS epoch, or even any
year in the past.  For times not known to be current times, I think one
needs to go back to the UNIX epoch start.

> If the date is before the build date, add 1024 weeks until it isn't.
>
> You can use the release date rather than the build date if you want 
> reproducible builds.

Or if you want this to work if the clock was wrong on the build system!

And agreed - that's what I came up with thinking about it.

I'll have a look at the gpsd code post release.