Dies scheint ein bekannter System-/Softwarefehler zu sein:
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
und von der gpsd-Manpage http://www.catb.org/gpsd/gpsd.html:
Es gibt genau zwei Umstände, unter denen sich gpsd auf die Systemuhr des Hosts verlässt:
Im GPS-Rundfunksignal wird die GPS-Zeit durch eine Wochennummer dargestellt, die je nach Raumfahrzeug nach 2^10 oder 2^13 Wochen (etwa 19,6 Jahre oder 157 Jahre) überläuft. Empfänger müssen dies auf das richtige Datum eindeutig machen, können jedoch Schwierigkeiten haben, da sie die Zeit nicht innerhalb der Hälfte dieses Intervalls kennen, oder können Fehler haben. Benutzer haben falsche Datumsangaben gemeldet, die anscheinend auf dieses Problem zurückzuführen sind. gpsd verwendet die Startzeit des Daemons zur Erkennung und Kompensierung von Rollovers während der Ausführung, meldet aber ansonsten das Datum so, wie es vom Empfänger gemeldet wird, ohne zu versuchen, es zu korrigieren.
Wenn Sie ein reines NMEA-GPS verwenden (d. h. SiRF oder Garmin oder den Zodiac-Binärmodus nicht verwenden), verlässt sich gpsd auf die Systemuhr, um ihm das aktuelle Jahrhundert mitzuteilen. Wenn die Systemuhr einen ungültigen Wert nahe Null zurückgibt und das GPS zu Beginn seines Aktualisierungszyklus kein GPZDA ausgibt (was bei den meisten NMEA-GPS für Verbraucher nicht der Fall ist), kann der Jahrhundertteil der Daten, die gpsd liefert, falsch sein. Darüber hinaus kann in der Nähe des Jahrhundertwechsels ein Datumsbereich, der in Sekunden so groß ist wie die Genauigkeit Ihrer Systemuhr, auf das falsche Jahrhundert verwiesen werden.
Ich habe gerade dieses Problem gelöst.
Der Beitrag von AndreJ ist genau und hat mir geholfen, meine Untersuchung zu beginnen, warum die Systemuhr so weit daneben lag.
In meinem Fall verbinde ich einen GPS-Empfänger mit einem Raspberry Pi 2, auf dem Ubuntu 14.04 ausgeführt wird. Raspberry Pis haben keine Hardware-Uhren und so früh im Boot-Prozess, bevor ntp die Uhr einstellen kann, werden Zeit und Datum nahe am Beginn der Epoche (1. Januar 1970) eingestellt.
Dies verwirrt gpsd:"Jan 1 00:00:13 ubuntu gpsd[814]:gpsd:ERROR:Systemzeit sieht falsch aus, Daten sind möglicherweise nicht zuverlässig."
Die Lösung für mich besteht darin, 'fake-hwclock' auszuführen, das das genaue Datum / die genaue Uhrzeit in einer Datei speichert und dann die Systemuhr aus dieser Datei sehr früh im Startvorgang einstellt. Selbst wenn Ihr Computer keine Hardware-Uhr mit Batterie hat und für eine Weile ausgeschaltet war, ist diese Datums-/Uhrzeiteinstellung genau genug, damit gpsd „das korrekte Datum bestimmen“ kann.