1 #ifndef _GPSD_TIMEBASE_H_
2 #define _GPSD_TIMEBASE_H_
4 /* timebase.h -- constants that will require patching over time */
6 * The current (fixed) leap-second correction, and the future Unix
7 * time after which to start hunting leap-second corrections from GPS
8 * subframe data if the GPS doesn't supply them any more readily.
10 * Deferring the check is a hack to speed up fix acquisition --
11 * subframe data is bulky enough to substantially increase latency.
12 * To update LEAP_SECONDS and START_SUBFRAME, see the IERS leap-second
14 * <http://hpiers.obspm.fr/eop-pc/products/bulletins/bulletins.html>
16 * You can use the Python expression
17 * time.mktime(time.strptime(... , "%d %b %Y %H:%M:%S"))
18 * to generate an integer value for START_SUBFRAME, or use the
19 * -n option of devtools/leapsecond.py in the source distribution
23 * This constant is used to get UTC from chipsets that report GPS time only.
25 * It's not a disaster if it's wrong; most such chips get the offset
26 * from some report abstracted from the subframe data, so their worst
27 * case is their time info will be incorrect for the remainder of an
28 * entire GPS message cycle (about 22 minutes) if you start gpsd up
29 * right after a leap-second.
31 * This value is only critical if the chipset gets GPS time only and
32 * not the offset; in this case gpsd will always report UTC that is exactly
33 * as incorrect as the constant. Currently this is true only for the
36 #define LEAP_SECONDS 15
38 /* Date of next possible leap second adjustment, according to IERS
40 #define START_SUBFRAME 1293857999 /* 31 Dec 2010 23:59:59 */
43 * This is used only when an NMEA device issues a two-digit year in a GPRMC
44 * and there has been no previous ZDA to set the year. We used to
45 * query the system clock for this, but there's no good way to cope
46 * with the mess if the system clock has been zeroed.
48 #define CENTURY_BASE 2000
50 /* timebase.h ends here */
51 #endif /* _GPSD_TIMEBASE_H_ */