Re: [gpsd-dev] GPSD's assumptions about time

[Sanjeev Gupta]

On Tue, Nov 26, 2013 at 5:47 PM, Eric S. Raymond <address@hidden> wrote:

The following is the header comment of timebase.c.  Please criticize,
amplify and correct.  In particular, I need to know (and document) how
often the leap second is actually transmitted.

All of gpsd's assumptions about time and GPS time reporting live in this file.

This is a work in progress.  Currently GPSD requires that the host system
clock be accurate to within one second.  It would be nice to relax this
to "accurate within one GPS rollover period" for receivers reporting
GPS week+TOW, but isn't possible in general.

Date and time in GPS is represented as number of weeks

+ (modulo 1024)

 

from the start
of zero second of 6 January 1980, plus number of seconds into the
week.  GPS time is not leap-second corrected, though satellites also
broadcast a current leap-second correction which is updated on

 
- six-month boundaries

+ three-month boundaries (Dec, Jun, Mar, and Sep; although all previous corrections have been in Dec or Jun)

 

according to rotational bulletins issued by the
International Earth Rotation and Reference Systems Service (IERS).

<snip>

 

2) Many NMEA devices - in fact, all that don't report ZDA - never tell
us what century they think it is. Those that do report century are
still subject to rollover problems. We need an external time reference
for this, too.

# Wouldn't an fstat on the gpsd binary give us a good idea of the century we are in?

# the st_mtime returned will give us the time that gpsd was installed, and we can

# assume that we are at some later point than that.

 

3) Supposing we're looking at a binary protocol that returns week/tow,
we can't know which rollover period we're in without an external time
source.

# see above

.
Conclusion: if the system clock isn't accurate enough that we can deduce
what rollover period we're in, we're utterly hosed. Furthermore, if it's
not accurate to within a second and only NMEA devices are reporting,
we don't even know what century it is!

# I think we (and by "we", I mean "you" are over-thinking the issue.  No amount of effort and design may be enough to solve a problem where the inputs are wron, misleading, or being kept confidential.

--
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane