[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] gpsd rolls back to 1999
From: |
Greg Troxel |
Subject: |
Re: [gpsd-dev] gpsd rolls back to 1999 |
Date: |
Fri, 28 Jun 2019 13:31:34 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (berkeley-unix) |
>> Can someone explain "magic calendar hack"? Maybe that is addressing a
>> different receiver bug.
>
> Have a good hard look at ntpd/ntp_wrapdate.c. The functions unfold_century()
> and eval_gp_time() are clrarly doing morte elaborate versions of this sort
> of periodic extension.
I am assuming you are referring to
https://gitlab.com/NTPsec/ntpsec/blob/master/ntpd/ntp_wrapdate.c
I see - there are multiple things going on here, and it would be good
to try to keep them separated as much as we can:
dealing with a time that is seconds since the GPS epoch, or
equivalently week number and seconds of week. This is the main thing,
for devices that report in seconds. I'll call this the W1K problem.
dealing with devices that report two digit years, or Y2K.
trying to use the leapsecond field to figure out the W1K epock, by
having some table of known values for various years.
Some computers have 32-bit time_t
Some computers boot up with 0 in unix timeval, so we can't assume the
system clock is even close.
and my approach is
Pick a W1K pivot, 2018-07-01, and advance by W1K units until >=.
Use 70 or 80 as the pivot for Y2K for now (and deal with 2070 by
2050). I tend to 70, because while 80 is GPS epoch start, 70 is
timeval, and it feels like asking for trouble to put 79 as 2079,
especially since no reasonable system will see either for almost 60
years. If presented with a time only in NMEA and not seconds, apply
this rule to the YY to get YYYY and then convert to seconds since GPS
epoch and then apply the W1K fixup.
Don't try to use leapseconds to guess epoch. Receivers seem to boot
up with leapseconds from their firmware and then get a new value.
This just feels way too complicated, and the "add W1K if t < pivot,
repeat" approach seems entirely adequate.
Assume people upgrade to a 64-bit time_t and don't worry about that at
all.
Don't use the system clock at all in processing time data from a GPSr.
I can appreciate the nerd tendency to extrat the most information from
various broken processes, and backing out leapsecond data is cool, but I
don't see it as solving a problem that the YY->YYYY and W1K fixups
don't. I get it that it might deal with 2150 now, but I see little
point in that. The right fix is not to make ntp/gpsd smarter by then,
but to stop using two digit years.
- Re: [gpsd-dev] gpsd rolls back to 1999, (continued)
- Re: [gpsd-dev] gpsd rolls back to 1999, Eric S. Raymond, 2019/06/22
- Re: [gpsd-dev] gpsd rolls back to 1999, Gary E. Miller, 2019/06/22
- Re: [gpsd-dev] gpsd rolls back to 1999, Sanjeev Gupta, 2019/06/26
- Re: [gpsd-dev] gpsd rolls back to 1999, Eric S. Raymond, 2019/06/26
- Re: [gpsd-dev] gpsd rolls back to 1999, Greg Troxel, 2019/06/26
- Re: [gpsd-dev] gpsd rolls back to 1999, Gary E. Miller, 2019/06/26
- Re: [gpsd-dev] gpsd rolls back to 1999, Sanjeev Gupta, 2019/06/28
- Re: [gpsd-dev] gpsd rolls back to 1999, Eric S. Raymond, 2019/06/28
- Re: [gpsd-dev] gpsd rolls back to 1999, Greg Troxel, 2019/06/28
- Re: [gpsd-dev] gpsd rolls back to 1999, Eric S. Raymond, 2019/06/28
- Re: [gpsd-dev] gpsd rolls back to 1999,
Greg Troxel <=
- Re: [gpsd-dev] gpsd rolls back to 1999, Eric S. Raymond, 2019/06/28
- Re: [gpsd-dev] gpsd rolls back to 1999, Hal Murray, 2019/06/28
- Re: [gpsd-dev] gpsd rolls back to 1999, Greg Troxel, 2019/06/29
- Re: [gpsd-dev] gpsd rolls back to 1999, Hal Murray, 2019/06/28
- Re: [gpsd-dev] gpsd rolls back to 1999, Eric S. Raymond, 2019/06/28
- Re: [gpsd-dev] gpsd rolls back to 1999, Greg Troxel, 2019/06/29
- Re: [gpsd-dev] gpsd rolls back to 1999, Michael J. Tubby B.Sc. MIET, 2019/06/29
- Re: [gpsd-dev] gpsd rolls back to 1999, Greg Troxel, 2019/06/29
- Re: [gpsd-dev] gpsd rolls back to 1999, Hal Murray, 2019/06/29
- Re: [gpsd-dev] gpsd rolls back to 1999, Greg Troxel, 2019/06/29