Zo hard is dat niet te stellen. De meeste NTP software is zo gemaakt dat een dergelijke tijdsprong als niet geldig gezien
wordt en de klok blijft dan "doorhobbelen" op de laatste sync die daarvoor gedaan is. Ook heeft een beetje timeserver
zelfs als die een lokale GPS referentie heeft tevens ook enkele netwerk time servers geconfigureerd staan waardoor dit
soort fouten ook na bijv een herstart weer herkend wordt (de lokale GPS zegt dat het 2002 is maar 3 netwerk timeservers
zeggen dat het 2021 is, dan blijft ie op 2021, en synct voortaan met die netwerk timeservers en negeert de GPS).
Echter dit geeft natuurlijk wel de ongewenste situatie dat de kennelijk geprefereerde GPS sync vervangen wordt door
een netwerk time sync. Als de boel een beetje gemonitord wordt valt dat op (stratum is ineens hoger), maar het kan zijn
dat we nog maanden of jaren tegen timeservers aan lopen die vroeger stratum 1 waren en nu ineens stratum 2 of hoger.

"dat je straks niet meer op systemen kun inloggen" dat zal alleen met wrakkig geconfigureerde systemen het geval zijn.

Rond 2060/2061 krijgen we weer zoiets.

Want ik weet dat er C routines in omloop zijn geweest waarbij de datum berekeningen slechts tot 2060/2061 goed werkten.

Wellicht is die software dan allang uit gefaseerd en zelf heb ik het in NIET kritische applicaties toen gebruikt maar het kan zijn dat deze foutieve datum routines door anderen in VITALE applicaties, is gebruikt.

Echter merk ik dat heel veel oude software nog steeds toegepast wordt in soms kritische functies.

puntje van aandacht.

(een ex developer die voor vele grote ict bedrijven heeft gewerkt)

Ik heb helaas alleen de datum kunnen onthouden waarop dit kritiek zou zijn want het is voor mij meer dan 30 jaar geleden.

Mannen ik kan de koeling van de kerncentrale niet bedienen omdat ik niet kan aanmelden.

Het was al nooit zo'n bijster goed idee om de NMEA-output van je GPS te gebruiken om de tijd te weten te komen. Een beetje serieuze time server gebruikt de PPS-output, en vertrouwt niet (of iig niet uitsluitend) op NMEA om die secondenpulsen te linken aan een kloktijd.

Hmm..opvallend, juist vandaag krijg ik tegen de verwachting in een update van Garmin navigatie voor de auto te verwerken. Of dat er mee te maken heeft weet ik op dit moment niet. Dus het wachten is op meer info.

Dus als ik het goed begrijp dan kunnen we straks het inloggen in onze eigen systemen wel vergeten?
Of geldt dit niet voor de PC gebruikers? En hoe zit het met de dashcams, elektrische fietsen etc, waar een GPS module inzit? Gaan die dan ook plat?

Nee hoor dat is "al" in 2038.

Daar staat het helemaal los van! Aan PPS heb je ook helemaal niks in dit geval, dat kan de tijd alleen +/- een halve seconde bepalen dus zeker niet voor 1024 weken.
Met NMEA heeft het ook niets te maken, als je device problemen geeft met NMEA dan waarschijnlijk ook in binaire mode, waar gpsd naar probeert om te schakelen als het device ondersteund wordt in binaire mode.

Waar het om gaat is dat een GPS device de datum alleen modulo-1024-weken kent en dat na 1024 weken het device slim moet worden om te snappen dat er een nieuwe periode is aangebroken, en dat ergens moet opslaan in nonvolatile storage.
Als een GPS device dat niet doet dan zal het na een koude start een verkeerde datum geven. Het kan dan nog zijn dat na vele minuten ineens de datum wel goed is want er is ergens een almanak bericht waarin wel de volledige datum staat, maar lang niet alle devices ondersteunen dat en de oudere satellieten zenden dit ook niet uit.

De meeste software probeert met andere externe informatie te bepalen wat de datum ongeveer is. Bijvoorbeeld door deze ook van een NTP server op te vragen, of door een CMOS klok te gebruiken, of een timestamp in een file ergens die eens per zoveel tijd ververst wordt.

Maar de gpsd programmeurs wilden iets maken wat totaal zonder externe informatie werkt. En daarbij is een van de programmeurs een beetje doorgeschoten in "slimheid": hij leest niet alleen het weeknummer uit de GPS ontvanger maar ook de informatie mbt "leap seconds". En heeft hard in de code gezet dat als de datum voorbij een bepaalde grens is en het aantal leap seconds is lager dan hij verwacht voor die datum, dat dan die datum waarschijnlijk fout is en er 1024 weken vanaf getrokken moet worden.

Dat was VERSCHRIKKELIJK DOM want hij is er vanuit gegaan dat het aantal leap seconds ongeveer lineair toeneemt met de tijd. En dat is helemaal niet zo! Er kunnen ook negatieve leap seconds zijn, en het kan zijn dat er jaren lang geen leap seconds zijn. Dat is al eerder voorgekomen, en nu weer. Nu gaat zijn slimme "if" de mist in!

Had men heel die trukerige code weg gelaten dan had het gewoon goed gewerkt, en was het enige probleem geweest dat je een of andere vorm van nonvolatile storage bij de hand moet hebben, of netwerktoegang. Door de koppigheid om daar niet vanuit te willen gaan is nu het hele product ineens in de problemen. Het ligt dus niet aan NMEA of de GPS devices, maar alleen aan de programmeur.
Laten we er van leren.

Het zou kunnen, want al eerder kwam Garmin met een update voor een GPS Week Number Rollover in 2019.
https://support.garmin.com/en-US/?faq=zWQY6Z2kFiAuY9kDnDBgZ6

Ik denk niet dat die update voor je Garmin er mee te maken heeft. Zoals gezegd was er in 2019 een rollover event. Toen moest de firmware van diverse Garmin GPS modellen aangepast worden, omdat ze anders de verkeerde datum zouden aangeven. Na deze update in 2019 lopen ze weer 19,7 jaar in de pas. Het lijkt me dat deze bug daar los van staat.

Ook TomTom heeft dit issue in haar oudere devices. Al geruime tijd is mijn TomTom Rider versie 2 niet meer in staat een datum / tijd te berekenen uit het GPS signaal :). Was voor TomTom ook een goede reden om de kaart-support te stoppen en je vriendelijk aan te bieden dat de oplossing voor het issue:' de aanschaf van de nieuweste versie van de TomTom Rider is'. ..

Deze bug is geen GPS week number rollover maar een door gpsd zelf ingebouwde "sanity check op leapseconds" die
nu de fout in gaat omdat leap seconds zich niet sane gedragen.

Er was een paar weken geleden ook al een ander probleem, omdat het aantal weken sinds de vorige leap second over
de 256 heen ging en daar gaan ook wat GPS ontvangers en bijbehorende software de mist mee in.
Maar omdat dit alleen een onterechte leap second gaf en dus hooguit een hikje van een seconde in de tijd (wat dan
meteen weer weg geregeld wordt) heeft niemand daar verder last van gehad.

Dit hele "modulo zoveel weken" gedoe in GPS heeft al ontzettend veel meer ellende gegeven dan die paar bits in
de navigatieberichten die ze er mee bespaard hebben! Als weeknummers gewoon 16 bits waren ipv 10 bits (en
zelfs 8 bits voor "weken tot eerstvolgende leapsecond") dan was al die ellende er niet geweest.

Voor mijn eigen Mio Mivue 785 (dashcam) was er wel een patch voor de week number rollover in 2019 (in dit model zit GPS), maar er wordt op de website niets vermeld over een komende GPS daemon rollover bug.

Ik kan mij niet voorstellen dat de fabrikant van deze dashcam heeft zitten slapen, maar wel wakker was in 2019.
Zo te zien is er geen probleem bij dit product.

Het is helemaal niet zeker dat zo'n apparaat intern met gpsd werkt. En dit is een probleem van gpsd, niet van GPS of
van een of ander veel gebruikte GPS ontvanger!
Alleen devices die intern met Linux werken gebruiken MOGELIJK gpsd, maar dit is niet zeker. Het is heel goed
mogelijk een dashcam of navigatie te maken die wel GPS heeft maar geen gpsd.

NTP-servers die gebruik maken van apparatuur van Meinberg, zoals time.nl, hebben iig geen last van de bug.
https://www.meinbergglobal.com/english/news/meinberg-products-not-affected-by-gpsd-bug.htm

Volgens de programmeur van gpsd wordt gpsd veel en op verschillende plekken gebruikt: "in mobiele embedded-systemen, en in de kaartservice op Android-telefoons. Het zit ook in drones, robotonderzeeërs en zelfrijdende auto's. Gpsd wordt daarnaast steeds vaker gebruikt in recente generaties bemande vliegtuigen, marinenavigatiesystemen en militaire voertuigen." Tegenover The Register zegt de programmeur van gpsd, Gary Miller, dat financiële instituten mogelijk in de problemen komen, als ze een gps-ntp-server gebruiken met de getroffen versie van gpsd erop. Op wat voor schaal het straks misgaat, is niet bekend.

Stop een timestamp (seconds since epoch, in dit geval 1 January 1970) in een 32-bit signed integer. What can go wrong?