gpspipe returns correct timestamp, but wrong date (21 dec 1995)
This seems to be a known system/software bug:
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
and from the gpsd manpage http://www.catb.org/gpsd/gpsd.html:
There are exactly two circumstances under which gpsd relies on the host-system clock:
In the GPS broadcast signal, GPS time is represented using a week number that rolls over after 2^10 or 2^13 weeks (about 19.6 years, or 157 years), depending on the spacecraft. Receivers are required to disambiguate this to the correct date, but may have difficulty due to not knowing time to within half this interval, or may have bugs. Users have reported incorrect dates which appear to be due to this issue. gpsd uses the startup time of the daemon detect and compensate for rollovers while it is running, but otherwise reports the date as it is reported by the receiver without attempting to correct it.
If you are using an NMEA-only GPS (that is, not using SiRF or Garmin or Zodiac binary mode), gpsd relies on the system clock to tell it the current century. If the system clock returns an invalid value near zero, and the GPS does not emit GPZDA at the start of its update cycle (which most consumer-grade NMEA GPSes do not) then the century part of the dates gpsd delivers may be wrong. Additionally, near the century turnover, a range of dates as wide in seconds as the accuracy of your system clock may be referred to the wrong century.
I just went through solving this problem.
The post by AndreJ is accurate and helped to start my investigation as to why the system clock was so far off.
In my case, I'm connecting a GPS receiver to a Raspberry Pi 2 running Ubuntu 14.04. Raspberry Pis don't have hardware clocks and so early in the boot process, before ntp can set the clock, the time/date are set close to the beginning of epoch (Jan 1 1970).
This confuses gpsd: "Jan 1 00:00:13 ubuntu gpsd[814]: gpsd:ERROR: system time looks bogus, dates may not be reliable."
The solution for me is to run 'fake-hwclock' which stores the accurate date/time in a file and then sets the system clock from that file very early in the boot process. Even if your machine lacks a hardware clock with battery and has been powered down for awhile, this date/time setting will be accurate enough for gpsd to be able to "disambiguate to the correct date."