Has been fixed in gpsd 3.23 and apparently bug is not present in 3.19 and earlier.
On Tuesday, October 19, 2021, 10:10:29 AM CDT, W1RS <deflatermaus@...> wrote:
Info from https://www.zdnet.com/article/thanks-to-a-nasty-gpsd-bug-real-life-time-travel-trouble-arrives-this-weekend/
WSJT users typically utilize frequent time synchronization via upstream time servers on the web. According to this article, "a nasty bug's been uncovered in GPSD that's going to pop up on October 24, 2021. If left unpatched, it's going to switch your time to some time in March 2012, and your system will crash."
NTP determines what time it is by synchronizing NTP servers with atomic clocks. NTP is based on a hierarchy of levels, where each level is assigned a number called the stratum. Stratum 1 (primary) servers at the lowest level are directly synchronized to national time services via satellite, radio, or modem. Stratum 2 (secondary) servers are synchronized to stratum 1 servers and so on. Usually, NTP clients and servers connect to Stratum 2 servers.
How do stratum 1 servers sync up with clocks? Many of them use GPSD. This service daemon monitors one or more GPSes for location, course, velocity, and for our purposes, the most important element it tracks is time. This code, which is a mix of a linkable C service library, a C++ wrapper class, and a Python module, has, like all programs, its fair share of bugs. Recently it was discovered that a bug in the time rollback (aka "GPS Week Rollover") sanity checking code scheduled for November 2038 will instead cause 1,024 to be subtracted from the October 24, 2021 week number. In other words, a lot of computers are in for a quick, sharp visit to March 2002.
So, check your systems now for this problem. And, if, like most of us, you're relying on someone upstream from you for the correct time, check with them to make sure they've taken care of this forthcoming trouble.
See more in the article....