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

[Eric S. Raymond]

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. 

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

The stance from which that was written was that I was trying to figure out
how to make GPSD an entirely autonomous time source so that it could be
used to *set* the system clock, e.g. on reboot of a navigation system on
an autonomous sub a thousand miles from the nearest Internet.

For GPSD, this is is a no-shit real deployment case.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>