>> We could test fixup software by setting the system clock
>> ahead far enough to look like GPS had rolled over.
> What kind of fixup? I looked long and hard at this problem in the context
> of GPSD. I never found one that wasn't as bad - or worse - than relying on
> the sysrem clock date.
I
Hal Murray :
>
> >> How many of the NMEA devices have GPS rollover problems?
> >> (either now or soon)
>
> > It's impossible to tell. When a device will roll over is, because of the
> > pivot-date trick, not a function of its hardware type but of its firmware
> > release. --
>
> Are there any
>> How many of the NMEA devices have GPS rollover problems?
>> (either now or soon)
> It's impossible to tell. When a device will roll over is, because of the
> pivot-date trick, not a function of its hardware type but of its firmware
> release. --
Are there any known examples?
I have a coll
Hal Murray :
> How many of the NMEA devices have GPS rollover problems? (either now or soon)
It's impossible to tell. When a device will roll over is, because of the
pivot-date trick, not a function of its hardware type but of its
firmware release.
--
http://www.catb.org/~esr/";
How many of the NMEA devices have GPS rollover problems? (either now or soon)
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Hal Murray :
> The problem I'm interested in is not Y2K, it's GPS rollover. 1024 weeks is
> not an integral number of years. The day and month are garbage too.
Right, not the same problem.
> I agree this is a mess. I think we need a flag to go with with the year.
> Then we can update the dr
