これは既知のシステム/ソフトウェア バグのようです:
http://forums.gpsreview.net/discussion/29425/garmin-gps-iii-plus-date-problem
http://continuouswave.com/ubb/Forum6/HTML/002815.html
http://www.colorado.edu/geography/gcraft/notes/gps/gpseow.htm
gpsd マンページ http://www.catb.org/gpsd/gpsd.html から:
<ブロック引用>gpsd がホスト システムのクロックに依存する状況は、正確に 2 つあります。
GPS ブロードキャスト信号では、GPS 時刻は、宇宙船に応じて 2^10 または 2^13 週間 (約 19.6 年または 157 年) 後にロールオーバーする週番号を使用して表されます。受信者はこれを正しい日付に明確にする必要がありますが、この間隔の半分以内の時間がわからないために問題が発生したり、バグがある可能性があります.ユーザーは、この問題が原因であると思われる誤った日付を報告しています.gpsd は、デーモンの起動時間を検出し、実行中のロールオーバーを補正しますが、それ以外の場合は、修正を試みることなく、受信者によって報告された日付を報告します.
NMEA のみの GPS を使用している (つまり、SiRF または Garminor Zodiac バイナリ モードを使用していない) 場合、gpsd はシステム クロックに依存して現在の世紀を伝えます。システム クロックがゼロに近い無効な値を返し、GPS が更新サイクルの開始時に GPZDA を発行しない場合 (ほとんどの消費者向け NMEA GPS は発行しません)、gpsd が提供する日付の世紀の部分が間違っている可能性があります。さらに、世紀転換の近くで、システム クロックの精度と同じ秒数の範囲の日付が間違った世紀を参照する可能性があります。
私はちょうどこの問題を解決しました。
AndreJ の投稿は正確であり、システム クロックがこれほど離れていた理由について調査を開始するのに役立ちました。
私の場合、Ubuntu 14.04 を実行している Raspberry Pi 2 に GPS 受信機を接続しています。 Raspberry Pi にはハードウェア クロックがないため、ブート プロセスの早い段階で、ntp がクロックを設定する前に、時間/日付がエポックの開始 (1970 年 1 月 1 日) 近くに設定されます。
これは gpsd を混乱させます。
私にとっての解決策は、正確な日付/時刻をファイルに保存し、ブートプロセスの非常に早い段階でそのファイルからシステムクロックを設定する「fake-hwclock」を実行することです。お使いのマシンにバッテリー付きのハードウェア クロックがなく、しばらく電源がオフになっている場合でも、この日付/時刻設定は、gpsd が「正しい日付を明確にする」ことができるほど正確です。