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

[Sanjeev Gupta]

On Wed, Nov 27, 2013 at 12:37 AM, Eric S. Raymond <address@hidden> wrote:

Sanjeev Gupta <address@hidden>:

> 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.

That's an interesting idea.  That is, using external file timestamps as
a reference in case the system clock has been lost.  That might enable
us to detect that a GPS rollover has occurred.

A more self-contained version of this idea would be to include the
current GPS week in the build; if we ever see GPS time resolving to
a week earlier than that, we can bump the rollover counter.  That
will work unless we're cold-starting so long after the build that
we're in the *second* following rollover period.  Since GPS is going
to 13-bit week counters that would be upwards of 157 years, which is
probably well over the design lifetime of any of our deployments.

Even with a 12-bit counter, if someone installs gpsd, and does not update it for 19 years, and has no network access, and buys a GPS device that refuses to give us century info, and has a poor antenna placement such that we cannot build a full almanac due to dropouts, and has a partial view of the sky that no satellite is visible for 12.5 minutes continuously, etc, what can I say, but:

   "What are you doing building a Safety-of-Life application?"

Or:

   "You keep using that word.  I do not think it means what you think it means"

Eric, Gary, Greg, et al, how much can you save me from my poor design choices?

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