Well, some other comments indicate that this might affect NTP servers? Would that indicate some kind of follow on effect on database timestamps? Timezone localisation/conversions? Replication setups?
Most people using NTP servers do not use GPS units directly, but sync them to public NTP servers - for example https://www.ntppool.org/en/. Redhat for example ships these as the default upstream NTP servers. if the ntppool.org servers use GPS and gpsd, they are likely to have patched the issue well in advance.
I work in a business where we do use serial and network connected GPS devices as stratum 0 timesources for NTP, and yes we have concerns about the implications of this bug on some of our remote devices. If the gpsd starts sending incorrect time/date to the local ntpd it will probably be marked as a false ticker. We have multiple GPS based NTP servers in our datacenters as fallbacks, however we will probably need to check for a firmware update from them for this issue from the vendor.
It most likely does not. You can get accurate (down to ~10ms) time from other NTP sources. What you want from a GPS based NTP server is the PPS output, which is accurate to a few ns.
