VS waarschuwen voor kans op mondiale gps-tijdssynchronisatieproblemen op zondag

De Amerikaanse Cybersecurity & Infrastructure Security Agency, of CISA, waarschuwt voor mogelijke gps-problemen die zich vanaf zondag voor kunnen doen. Door een bug in bepaalde gpsd-servicedaemon-versies zal de interne klok van apparaten bijna 20 jaar terugspringen.

Het gaat volgens de waarschuwing om apparaten die gpsd versie 3.20, 3.21 of 3.22 draaien. Die versies van de daemon zijn uitgebracht tussen 31 december 2019 en 8 januari 2021. Versie 3.23 kwam uit op 6 augustus van dit jaar, waardoor er een periode van iets meer dan anderhalf jaar bestaat waarin die toentertijd nieuwste versie van gpsd de bug had. CISA 'adviseert beheerders van kritieke stukken infrastructuur die gpsd gebruiken om de tijd bij te houden, om te controleren of ze gpsd versie 3.23 of nieuwer draaien'.

Gps-software heeft wel eens te maken met een roll-over-moment, maar dat gebeurt eens in de 1024 weken, of 19,6 jaar, en die gebeurtenis heeft in 2019 al plaatsgevonden. Dat is dan ook niet waar deze bug om gaat: het probleem ligt bij een rekenfout die gemaakt is in een stuk code dat geschreven is om te anticiperen op een schrikkelseconde, die zich ergens in de toekomst gaat voordoen. Als de bug aanwezig is in een systeem, zal deze zich voordoen bij het aanbreken van de zondag en gaat de tijd op het gps-apparaat terug naar maart 2002. Als dat gebeurt, is de kans groot dat een dienst spaak loopt.

Volgens de man achter gpsd wordt het systeem op veel en 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.

Reacties (130)

[Technomania]

Er zal waarschijnlijk weinig gebeuren net als met de Millenniumbug destijds.

edit: @Creesch Ah, dat stukje dat men met man en macht aan heeft gewerkt was mij alweer ontschoten. Bedankt voor de toevoeging.

[Reactie gewijzigd door Technomania op 25 juli 2024 04:47]

[Creesch]

net als met de Millenniumbug destijds.

De reden dat er bij de millenniumbug destijds zo weinig gebeurde is omdat men er met man en macht aan heeft gewerkt om te zorgen dat het geen probleem zou zijn. Je ziet dit zo vaak voorbij komen, ook met andere zaken maar het zou juist raar zijn geweest als ondanks alle campagnes en aandacht er voor er wel enorm grote problemen waren geweest want dan hadden een hoop ITers hun werk niet goed gedaan.

[RoestVrijStaal]

Duivels dilemma: Laat je het expres in de soep lopen zodat anderen inzien dat je onmisbaar bent of pak je het zo tijdig op dat het voor anderen haast een hypothetisch probleem lijkt te zijn?

[Iblies]

Even voor de goede orde,
je hebt Glanoss, Galileo, Beidou, en zelfs uit India NaviC. India vertrouwt de VS niet helemaal ivm hun continu eigen oplaaiend conflict met Pakistan en China vertrouwen ze ook niet.


Ik zie het juist meer als reclame voor de alternatieven.

[ramdejong74]

De vraag of dat meer betrouwbare alternatieven zijn.

[AlbertJP]

Veel 'gps'-apparaten ontvangen meerdere netwerken maar gebruiken de andere dan GPS alleen om de nauwkeurigheid te verbeteren -> in geval van twijfel wordt de GPS-data als het meest betrouwbaar gezien, daarmee is het alsnog vervelend als GPS verkeerde informatie doorgeeft.

[bluelion]

GPS geeft perfecte informatie, daar is niks mis mee.

Het is de opensource implementatie gpsd welke een rekenfout bevat.

[BeosBeing]

GPS geeft perfecte informatie, daar is niks mis mee.

Nu wel, maar de Amerikanen kunnen de nauwkeurigheid verminderen (voor hun eigen militairen was hij altijd nauwkeuriger dan voor het grote publiek) of het zelfs helemaal uitzetten, ofwel voor iedereen behalve hun eigen oorlogsmachine.

In die zin is het terecht dat Rusland, China; Europa, ... dat niet helemaal vertrouwen.

Het is de opensource implementatie gpsd welke een rekenfout bevat.

Dit keer wel, maar juist als er stront aan de knikker is, wil je niet afhankelijk zijn van wat misschien een rivaal of zelfs de vijand kan zijn.

[jjeggink]

Hoe kun je waarde X nauwkeuriger maken met waarde Y, als je X meer vertrouwd en deze aanhoud bij afwijkingen

[AlbertJP]

Bijvoorbeeld door het weggooien van meetdata die te ver verwijderd liggen van de rest en daarna het gemiddelde te bepalen.

In ieder geval geven de meeste apparaten simpelweg geen positie door als er alleen andere netwerken dan GPS ontvangen kunnen worden.

[jjeggink]

Ik snap wel hoe het werkt en wat je bedoeld, maar je formulering is krom.
Je kunt GPS-metingen verifiëren aan de hand van andere metingen. Daarbij kun je prima een melding laten verschijnen dat de GPS-metingen, die je als uitgangswaarde hanteerd, verder afwijken van de controle-metingen dan de vastgestelde grenswaarde. Maar je kunt GPS-metingen simpelweg niet nauwkeuriger maken door deze te vergelijken met andere metingen, om vervolgens deze alsnog te laten prevaleren bij afwijkingen. Anders gezegd, dat GPS over het algemeen als meest betrouwbaar wordt gezien (Galileo is, in elk geval voor civiele toepassingen, nauwkeuriger dan GPS maar dat is dan weer een andere discussie), maakt het nog niet altijd correct.

[bluelion]

Ja er zijn alternatieve systemen, maar dit is geen probleem met GPS, maar in een opensource implementatie van een applicatie software service.


BTW, het is Glonass niet Glanoss

[sheppy]

Glonass. Niet Glanoss.

[Risce]

Dat is geen dilemma hoor. Lijkt me niet zo belangrijk om je gelijk aan te tonen als de mogelijke effecten van niks doen zo enorm zijn.

[icecreamfarmer]

Dit dus.
Voorkom je een ramp dan is het geld weggegooid.

[Cerberus_tm]

Laten we de dijken maar afbreken, want we hebben toch nooit overstromingen.

[Tjidde]

vraag dat aan Limburg.

Maar IT is helaas een groot ondergesteld deel van veel organisaties. Waardoor juist dat soort bedrijven met dat soort it budgetten geraakt worden door dit soort problemen. En dan alles pp de IT afdeling gooien.

[YangWenli]

Mensen merken IT pas als op maandag ochtend de computer niet opstart. De vanzelfsprekendheid is dat alles goed gaat

[feuniks]

Iemand bij een klant waar ik een poos heb gewerkt, vroeg me eens wat ik eigenlijk daar deed. Ik heb haar toen verteld dat ik het een groot compliment vond dat ze niet wist wat ik deed, want dan deed ik mijn werk kennelijk erg goed.

[Deralte]

En, als de computer maandagochtend niet opstart, miet het onmiddellijk gefixt worden… ze doen immers een heel belangrijke job…

[jjeggink]

Als ze op vrijdagmiddag op tijd naar huis zijn gegaan is er maandagmorgen doorgaans ook niks aan de hand. Hebben ze een weekendje doorgehaald voor een 'grote update' of 'onderhoud van het systeem', tien tegen een dat maandagmorgen de boel op z'n gat ligt. Voor alle IT-ers; If it ain't broke, don't try to fix it! Als er iets is, dan bellen we wel. Tot die tijd, blijf lekker bij de koffieautomaat ouwehoeren.

[rdoorn]

ooit kon je het redden als it-er met dat motto: If it ain't broke, don't try to fix it!
Tegenwoordig is dat niet meer houdbaar. Je moet de systemen continue bijwerken, updates en beveiliging.

[jjeggink]

Voor het draaien van updates heb je toch geen IT-er nodig

[Sfynx]

Als alles op rolletjes loopt: "Waarom betalen we IT eigenlijk, ze zitten alleen maar de hele dag naar schermen met grafiekjes te kijken"

Als het misgaat: "Waarom betalen we IT eigenlijk"

[Tinboy]

Algemeen probleem van veel functies. Zolang zij hun werk kunnen doen, ziet niemand het. Denk aan schoonmakers, onderhoudsmonteurs in een fabriek, etc. Je ziet het pas wanneer het fout gaat.

Wie probleempjes snel op lost is een held. Wie ze voorkomt, wordt niet gezien.

Misschien een klein programmetje maken dat eens in de zoveel tijd een PC/laptob van management laat crashen. Kun je daarna 15min heel gewichtig doen om het weer te fixen, ben je weer even in beeld geweest. (En van te voren zeggen dat het zeker 30min gaat kosten voor bonus punten, omdat je eerder klaar bent dan verwacht:). )

[Havelock]

Sommige dingen weet je pas achteraf of het gewerkt heeft lijk me vrij logisch toch!

[field33P]

Eens in de zoveel tijd loopt er weer eens een stuk software in de soep als gevolg van een schrikkeljaar, soms met grote gevolgen. Daar is alleen minder focus op.

[Reactie gewijzigd door field33P op 25 juli 2024 04:47]

[Blokker_1999]

Maar dan gaat het niet om een veel gebruikt stukje software. Dit is een service die in vele andere systemen gebruikt wordt.

[DataGhost]

Die werd bovendien ook al jaren van tevoren gemeld. Niet slechts drie dagen van tevoren zoals deze (de bron waarschuwde hier eergisteren voor).

[ANdrode]

Het is al veel langer bekend - een collega van mij linkte nadat https://lwn.net/Articles/865044/ uit kwam al een gerelateerd artikel.

Het krijgt nu pas brede aandacht, dat is wat anders

[The Zep Man]

Die werd bovendien ook al jaren van tevoren gemeld. Niet slechts drie dagen van tevoren zoals deze (de bron waarschuwde hier eergisteren voor).

Vergelijkbaar met het 2038 probleem. We weten er op tijd vanaf, maar nu moet het nog opgelost worden. Gebeurt dat op tijd, hoor je er ook geen haan naar kraaien.

[DigitalExorcist]

Onzin natuurlijk, je hebt het nooit gelezen. Ik wél en het lijkt in niks op “de toestand” (welke dat ook moge zijn) waar “we” nu in leven.

Wel een goed verhaal verder, dat wel.

[Reactie gewijzigd door DigitalExorcist op 25 juli 2024 04:47]

[Argantonis]

Rare dingen, jaartallen... 1984 was ook zoiets....
George Orwell schreef een boek met die titel die al in 1949 werd uitgebracht.
De toestand waarin we nu leven doet sterk denken aan wat er in dat boek staat.

Oftewel: hoe zeg je dat je 1984 nooit hebt gelezen zonder letterlijk te zeggen dat je 1984 nooit hebt gelezen.

[Mariekeb]

Dat ja! Keihard aan gewerkt als toen startende ontwikkelaar. En later alsnog wel eens een klein probleem tegen gekomen ( iets met facturen,abonnement opzeggen en dan bizar veel geld terug krijgen)

[xenn99]

Ik ben destijds zelf onderdeel geweest van vele projecten omtrend de Y2K bug, en ik heb er toch een iets ander gevoel bij moet ik zeggen

Er waren zeker apparaten die niet goed met Y2K om konden gaan maar in mijn ervaring waren dat er echt heel erg weinig.

Wat meer gebeurde was dat de Y2K bug werd misbruikt door werknemers om zoveel mogelijk "oude hardware" weg te krijgen zodat ze nieuwe systemen kregen.
(Los van of het echt niet met Y2K overweg kon of niet.)

Natuurlijk, als er niets was gedaan waren er vast en zeker wel dingen mis gegaan,
maar om nou te zeggen dat het een grote chaos was geworden als er niet zoveel aandacht aan was besteed..
Van wat ik heb gezien lijkt me dat zeer onwaarschijnlijk.

De mediahype was veel groter dan het daadwerkelijke probleem.

[Frame164]

Mijn ervaring was juist dat we zoveel moesten aanpassen dat we het bijna niet voor elkaar kregen. Een week vantevoren werd nog het laatste systeem gepatcht, terwijl we toen al 2 weken inde gebruikelijke eindejaars network freeze periode zaten.

[armageddon_2k1]

Mooie n=1 waarneming.

"Mijn ervaring is anders, dus het daadwerkelijke probleem zal wel echt kleiner geweest zijn."

[YopY]

Dat zie je ook weer terug met de wappies omtrent corona, zeker een paar maanden geleden; ja het is niet zo'n groot probleem juist omdat we al die maatregelen hebben. Als het voelt alsof ze niet (meer) nodig zijn, dan werkt het.

[J_van_Ekris]

Er zal waarschijnlijk weinig gebeuren net als met de Millenniumbug destijds.

Als een van de mensen die aan de millennium-veerbereiding heeft meegewerkt kan ik je verzekeren dat er een hoop ellende is opgeruimd, en dat we echt wel aan behoorlijk wat ellende ontsnapt zijn.

[ernstoud]

Inderdaad. Ik werkte indertijd bij het Computer Uitwijk Centrum en bijvoorbeeld de Belastingdienst had op 1 januari 2000 geen systemen gehad. Bijvoorbeeld de HP9000 met alle stamtabellen was niet 2000 proof.

Om over de grootbanken maar niet te spreken.

[DjoeC]

Hmm, wij waren in de zeventiger-tachtiger jaren al bezig. Daar waar jaar 2 posities was kon je vrijwel altijd bepalen of het een "toekomstige" datum of 1 in het verleden moest zijn. Alleen 100+ jarigen kenden potentieel problemen. Gelukkig waren dat er niet zoveel.

Maar goed, consultancybedrijven waren er druk mee en hebben gouden jaren gehad. Ook India heeft ervan geprofiteerd. Jammer genoeg is die periode niet gebruikt om te vernieuwbouwen en ook toekomstige problemen te voorkomen. Alles was gericht op (symptoom)bestrijding, geld besteden soms tegen de adviezen van de interne deskundigen in. Niemand wilde het risico nemen....

Het was een vreemde tijd, ben benieuwd wat er met de 2038 bug gaat gebeuren.

[ernstoud]

In januari 2000 hadden veel grote IT gebruikers hun configuration management op orde. En daarna zakte het weer als een plumpudding in. Tekenend was bij de Belastingdienst dat begin 2000 alle systemen die gebouwd werden voor de 2000 problematiek ceremonieel uitgezet werden.

PWC had zelfs een heel congres georganiseerd hoe bedrijven nu met weinig moeite hun configuratie up-to-date konden houden. Dovemansoren.

[DjoeC]

Tja, je noemt nu een zeer bijzondere organsatie die hoewel ze zich graag als bedrijf presenteert slechts door de politiek (en daarbij horende JAARbudgetten) gestuurd wordt. Het is beslist niet te vergelijken met een bedrijf, zie de eerste paragraaf: https://nl.wikipedia.org/wiki/Bedrijf

[Reactie gewijzigd door DjoeC op 25 juli 2024 04:47]

[The Zep Man]

Tja, je noemt nu een zeer bijzondere organsatie die hoewel ze zich graag als bedrijf presenteert slecht door de politiek (en daarbij horende JAARbudgetten) gestuurd wordt.

Daarmee impliceer je dat niet-bijzondere bedrijven niet door jaarbudgetten gestuurd worden. Dit is onjuist. Zeker beursgenoteerde bedrijven kijken sneller naar de korte termijn.

[Reactie gewijzigd door The Zep Man op 25 juli 2024 04:47]

[Sfynx]

Het was een vreemde tijd, ben benieuwd wat er met de 2038 bug gaat gebeuren.

Je zou verwachten dat over 16 jaar het toch wel klaar is met de meeste 32-bits systemen, zodat het aantal systemen waar je specifieke aandacht aan moet besteden (dan denk ik aan embedded systemen, ruimtevaart e.d.) beperkt is.

In potentie zou dit wel een groter probleem kunnen worden anders.

[Reactie gewijzigd door Sfynx op 25 juli 2024 04:47]

[ikwilwp8]

Je kunt op een 32 bits systeem prima een int64 opslaan. Het zal dan ook alleen met oude, niet updatebare systemen problemen gaan geven.
Ik geloof niet dat het tegen die tijd al gedaan zal zijn met 32 bits systemen. PC's, jazeker. Embedded platformen, waarschijnlijk niet.

[Reactie gewijzigd door ikwilwp8 op 25 juli 2024 04:47]

[Niemand_Anders]

Wij hadden ook een zeer voorbereidingstrajact, maar er is altijd de vraag of je toch niet iets over het hoofd hebt gezien. Mijn werkgever zocht daarom administrators welke standy wouden staan tijdens oud & nieuw 2000 mocht er toch iets fout gaan. Ik werkte toen bij dat bedrijf iets meer dan 6 maanden (gestart als programmeur en sinds nov 1999 ook onderdeel van linux/windows admin team) dus initeel twijfelde ik persoonlijk of wel ik geschikt zou zijn. Uiteindelijk deed niemand zich melden en heb ik mijzelf alsnog vrijwillig gemeld omdat ik geen alcohol drink is nuchter blijven dus niet zo lastig. Je wilt na 5 glazen champagne/bier/wijn niet live aan een productie systeem werken. Uiteindelijk 1000 gulden verdient en uiteindelijk heb ik niet hoeven in te grijpen.

Twee jaar later kregen we de gulden/euro migratie en heb ik meerdere migratie scripts moeten starten na middernacht omdat veel betaalproviders geen euro bedragen accepteerde voor 2002 vooral omdat de euro pas sinds 1-1-2002 een wettig betaalmiddel was. Althans dat was een van de redenen welke wij destijds terug kregen van Bibit. Ook daar zat een voorbereiding van maanden aan vast en de migratie duurde uiteindelijk tussen de 5 en 90 minuten. Een van onze klanten had een spaarsysteem waarvan niet alleen de valuta veranderde, maar ook de conversie formule om het aantal punten te bepalen. Hierdoor moest het gehele kasboek per houder worden herberekend en daarna worden omgezet naar euro's.

Echter 2.20371 is een constante welke ik net als PI en de wortel uit 2 en 3 (veel gebruikt in elektrotechniek) nooit meer van mijn level zal vergeten. Het heeft mij
wel een nieuwe theorie opgeleverd over dementie. Je vergeet geen dingen omdat je ouder wordt, je hebt alleen zoveel nutteloze informatie in je hoofd zitten dat er gewoonweg geen plaats meer is voor nieuwe informatie... ;-)

[Makkelijk]

Leuk bedacht maar helaas werkt Alzheimer toch echt niet zo..

[Blurk62]

Al vanaf midden jaren 80 werden bij "ons" alle berekeningen die met een datum te maken hadden uitsluitend met een aantal apart aan te roepen routines uitgevoerd. Dan heb ik het over honderden Cobol programma's die hier gebruik van maakten. Het aantal bestanden met datums zonder eeuw aanduiding was zeer beperkt. Het hele millennium probleem stelde hierdoor eigenlijk weinig voor.
Natuurlijk is er voor de gemoedsrust van managers en klanten veel tijd besteed aan het testen, onder andere door in vele weekenden de klok van het mainframe aan te passen naar vlak vóór en vlak na de eeuwwisseling en door het schaduw draaien van veel batchwerk. Ik herinner me welgeteld één klein probleem met een stukje software van een externe partij.
Wat destijds eigenlijk spannender was, was het aanpassen van de systeemklok naar zomer- en wintertijd!

[TurboTon1973]

Een paar jaar terug had mijn autonavigatie last van die 19 jaar bug. Terwijl mijn auto van 2014 is.
Hierdoor klopte de navigatie ook niet. Gelukkig heb ik een update kunnen krijgen via de leverancier van de navigatie. Want mijn garage wist van niks.

Was een eerste wereld probleem. Maar wel een lastige

[Aapmansz]

Dat was in 2019. Renault heeft netjes de klanten met een Rlink TomTom systeem benaderd en geïnformeerd dat er een patch is. Overigens werd de melding over de update ook weergegeven op het navigatiescherm in de auto.

Helaas kon de update niet over the air en alleen gehatseflatst worden via een USB stick.

[TurboTon1973]

Ik heb een Suzuki, ik kreeg geen melding. Ik wist de oorzaak door tweakers en als een echte tweaker opgelost in mijn geval moest het met een sd kaart

[mbbs1024]

Daarmee hebben we indertijd, als geacrediteerd testlab een hoop geld mee verdiend, iedereen wou toen voor hun apparaten een certifikaat dat het Y2K proof was.
We hebben zelfs hopen apparaten, zoals bvb een oude mechanische telefoon met draaischijf, waar dus totaal geen tijdsafhankelijk mechanisme in zit, moeten certifiëren.

[ehgeahrev]

Zoek eens op de preventieparadox...

[DirtyBird]

Sinds wanneer is dit bekend? Dit lijkt me voor professionals geen nieuws toch? Ik mag hopen dat dit al eerder is ondervangen en google nu niet ineens denkt "oh, kut! Iedereen even naar kantoor om een paar uurtjes te buffelen"

[Bergen]

Sinds de bug werd aangetroffen op 21 juli. Hier staat de originele bugreport: https://gitlab.com/gpsd/gpsd/-/issues/144

[FreshMaker]

Sinds wanneer is dit bekend? Dit lijkt me voor professionals geen nieuws toch? Ik mag hopen dat dit al eerder is ondervangen en google nu niet ineens denkt "oh, kut! Iedereen even naar kantoor om een paar uurtjes te buffelen"

https://lwn.net/Articles/865044/

In ieder geval al in augustus 2021
Dus veel systemen zullen al wel op orde zijn.
Het is niet zo, dat CISA ineens alles kan voorspellen, ze zijn afhankelijk van informatie die ze krijgen, en gaan daarna pas inschatten hoever het KAN uitlopen

[Frij5fd]

Voor de lopers van de marathon van Rotterdam is dit morgen hopelijk geen probleem. Het is, als je serieus loopt, het beste om op een vlak tempo te lopen. En als je horloge dan geen correct tempo aangeeft is het toch lastig om dat op gevoel te doen. Alternatief is een footpod gebruiken.
Of, zoals ik vroeger deed, een stopwatch, en dan elke km de rondetijd checken

Edit: in 2019 trad ook een rollover-probleem op en toen gaf Garmin aan: "Positie, snelheid, navigatie en alle andere functies die niet afhankelijk zijn van datum en/of tijd blijven normaal werken"

[Reactie gewijzigd door Frij5fd op 25 juli 2024 04:47]

[MiesvanderLippe]

Garmin, Apple en Samsung hebben niet tot het Tweakers artikel gewacht met het patchen van hun zaken hoor, dit was al langer bekend. Bovendien is het maar de vraag of die systemen tijdens een workout een systeemtijd, een interne teller onafhankelijk van de systeemtijd, een netwerktijd, een GSM tijd of een GPS tijd gebruiken.

[Frij5fd]

In 2019 was Garmin niet op tijd: https://support.garmin.com/nl-NL/?faq=aWFo5DwVSv0cCJgWFoUXd9
Als developer van Garmin apps voor de horloges weet ik dat GPS-tijd en datum in de devices gebruikt worden.
Maar ik zag wel dat in 2019 tempo niet aangetast werd (zie ook de edit in mijn vorige post)

[Aapmansz]

Dat zal dan per productgroep geweest zijn. Mijn 15 jaar oude Garmin GPSMAP60CSX had geen last van deze 2019 bug ondanks dat het apparaat al jaren niet meer geüpdatet was.

Ter lering en vermaak het ongebruikte apparaat van batterijen voorzien om te zien wat er gebeurde na apr 2019. Zal het apparaat volgende week nog eens aanslingeren.

[kodak]

Dat is een te makkelijke bewering. Ten eerste omdat je niet duidelijk maakt waaruit dat uitgeven van updates blijkt. En dan is er nog het risico dat mensen hun software niet updaten als er wel een oplossing is.

[PatrickC]

Dan moeten die horloges wel gepatched worden en er zijn genoeg horloges in gebruik die al lang geen firmware updates meer krijgen.

[DataGhost]

Systemen die een tempo berekenen doen dat door de verstreken tijd tussen begin en eind uit te rekenen. Of dat systeem morgen nou denkt of het 24 oktober 2021 of 3 maart 2002 is maakt dus helemaal niks uit, aangezien je (bijv.) zowel start als finisht in 2002. Er is geen mix van beide. De rollover is vannacht, dus het zal alleen misschien mis kunnen gaan als je vanavond al begint met lopen.

[J_van_Ekris]

Tenzij je race start op 24 oktober 2021, en eindigt op 33 maart 2002, dan heb je zojuist -19,5 jaar gelopen....

[Barsonax]

Dat ligt er net aan hoe de berekening gaat.

In de DateTime van C# wordt volgens mij intern het aantal ticks bijgehouden in een long. Als je dan op basis van het verschil in ticks rekent heb je dit probleem niet volgens mij.

[Argantonis]

Dat het dataformaat onder de motorkap een long is zegt niks over deze bug. Dat is bij het merendeel van fatsoenlijke dataformaten voor datum en tijd zo. C# heeft dat met een tick vanaf het jaar 0001, Java heeft dat vanaf het jaar 1970 (met negatieve getallen daarvoor), et cetera. Maar dat betekent niet dat elk DateTime object een eigen countertje heeft dat dingen gaat zitten ophogen. Het is nog steeds afhankelijk van de systeemtijd.

[supersnathan94]

You must’ve hit 88miles an hour.

[DaveFlash]

Great Scott!

[JeroenED]

Het lijkt mij meer op dat deze hooguit verkeerde locaties zal aangeven dan echt verkeerd tempo.

Bedenking achteraf: kan wel zijn want door de datumaanpassing gebruik je de verkeerde verwachtte satteliet locaties die mogelijks veel verder uit elkaar liggen dan in maart 2002

[Niek_Luinge]

Ik heb hier de ballen verstand van, maar mijn radiografisch gestuurde klok ging een paar dagen geleden ineens heel veel uren vooruit en loopt sindsdien niet goed meer, vanmiddag even de batterij eruit gehaald en weer erin, toen ging hij ook weer een heel stuk draaien maar helaas ging hij weer op een verkeerd tijdstip lopen.
Kan dat hier mee te maken hebben? Ik heb er echt geen verstand van

[CPV]

Die klokken hebben niets met GPS te maken, die tijd komt via een radiosignaal uit de buurt van Frankfurt.
Maar die van mij stond een week geleden helemaal stil op een onzinnige tijd. Ook de batterij er even uit en toen heeft hij 's nachts de tijd weer opgepikt.

[Niek_Luinge]

Hmmm dan ga ik dat ook proberen, ik heb de batterij eruit gehaald en doe ze er morgen weer in. Op hoop van zege!

[CPV]

Je moet de batterijen er even uithalen om hem te resetten. De tijd staat dan op 01-01-80 als ik me goed herinner. Iedere nacht (rond 02:00) wordt een synchronisatiesignaal gestuurd en dan is de tijd weer gelijk. Hij moet wel verbinding met de zender hebben, ik kan het zien aan een zender-icoon op het display.
Hoewel er ook klokken op het gps signaal blijken te bestaan, Even zoeken in de handleiding waar hij zijn tijd vandaan haalt.
https://nl.wikipedia.org/wiki/Radiografische_klok

[Niek_Luinge]

Hmm, ik heb hem de hele nacht zonder batterij gelaten, vanochtend er weer in, hij gaat direct weer flink draaien. Hij loopt nu tot op de seconde keurig precies 4 uur achter.. Hij loopt keurig door, maar dan 4 uur te vroeg, dat gebeurt telkens bij het resetten weer. Vreemd.. Ik heb er geen boekje bij.

[Andrejan]

Mijn klok in de keuken wordt ook radiografisch aangestuurd, en het gebeurt hier af en toe ook dat hij exact 4 uur achterloopt. Dat is voor mij altijd het signaal dat de batterij (te) zwak begint te worden. Je kunt voor de zekerheid nog 24 uur wachten, maar als hij dan nog steeds precies 4 uur achterloopt zou ik een verse batterij proberen.

[CPV]

Vrijwel alle handleidingen die ooit geschreven zijn, zijn tegenwoordig op internet terug te vinden. Probeer het eens.

[Annihlator]

Gps-assisted time synchronisation is wel een "cost-effective" methode, het zou dus zo kúnnen zijn

[g_v_rijn]

Afhankelijk van de software GPS versie op een device - staat te lezen!
Dus contact de leverancier / producent.

[Leemeijer]

Hebben satelieten hier ook last van?

[DeCo]

nee, die zijn niet afhankelijk van deze systemen

[Bergen]

Nee, de software waar de bug in zit (gpsd) wordt in gps receivers gebruikt.

[iSpaceman]

Ze komen er wel een beetje laat mee zeg, is morgen al. Als je nu nog alles moet aanpassen ben je eigenlijk al te laat. Hopelijk zal het niet voor veel problemen zorgen.

[Bergen]

Ja, de bug werd op 21 juli 'al' ontdekt, maar nu de grens nadert wordt er pas ruchtbaarheid aan gegeven.

[Frame164]

Een beetje beheerder weet dit al maanden. Een beheerder die dit niet wist moet eens achter z’n oren gaan krabben en afvragen of hij wel geschikt is voor het werk.

[Mushroomician]

Wat aardig en lief van de VS om ons daarop te attenderen. Helaas weer niets van onze eigen Ministeries gehoord. Als er niet snel verbetering komt in de autonomie en digitale soevereiniteit van de EU, gok ik dat we tegen 2050 ongeveer een soort 2e rangs staat worden van de VS.

[Reactie gewijzigd door Mushroomician op 25 juli 2024 04:47]

[marco275]

Kan me voorstellen dat ze hier niet eens iets van wisten tot de VS met het nieuws kwam.
Dat is ook de reden dat we nu ons eigen Europese GPS-systeem hebben.

[Frame164]

Het is al lang bekend.

[BlackOwl]

Zijn we al.
En gezien het feit dat zowel het EU bestuur als de landelijke regeringen hier wel blij mee zij kun je veilig aannemen dat het zo blijft.

[bbr]

En, hoe laat ongeveer?
Heeft dit zich niet ook eerder voorgedaan?

[Playa del C.]

Bij het aanbreken van de zondag. Dus om 00:00 uur.

[casberrypi]

In welke tijdzone?

[Playa del C.]

In de 'eigen tijdzone'. Het is een software bug die in de lokale systemen plaatsvindt. Om 00:00 uur vind de roll-over van een waarde plaats.
Zie: https://en.m.wikipedia.org/wiki/GPS_week_number_rollover

[.oisyn]

Dit heeft dan weer niets met de week number rollover te maken (die was in 2019), en bovendien was dat juist weer UTC, niet de lokale tijd.

[DataGhost]

UTC lijkt me het meest waarschijnlijk aangezien dat is waar het systeem in werkt. Alle vertalingen naar lokale tijdzones zijn relatief ten opzichte van UTC.

[Mel33]

Interessante vraag... je zou zeggen op elke moment als het in die tijdzone zondag wordt. Maar ik heb ook de twijfel, want als het ergens zondag wordt kan het de satelliet ernaast ook niet meer goed syncen lijkt mij.

[Roel1966]

Ik dacht eerst even dat dit te maken had met het 1 uur terug zetten van de klok maar dat is pas volgende week. Maar zoals ik lees heeft dit dan met een bepaalde berekening te maken waarbij het wel eens mis kan gaan zoals blijkt. Nu kom ik dan nog uit een tijd dat je een gewone landkaart gebruikte om je route te bepalen en je geen last had van GPS bugs. Zelfs tegenwoordig vertrouw ik niet op navigatie en kijk altijd nog van te voren even op een kaart.

[bytemaster460]

Voor het navigeren zal het weinig effect hebben. Het gaat meer om aanvullende diensten die gebruik maken van een datum.

[Roel1966]

Dat is mij toch niet echt duidelijk vanuit het artikel dat het op navigeren weinig effect zal hebben, eerder dat er in de laatste alinea staat

Op wat voor schaal het straks misgaat, is niet bekend

Dus in hoeverre het weinig of geen invloed heeft moeten we denk ik nog maar eens afwachten. Bedenk daarbij dat veel tegenwoordig aan elkaar gekoppeld zit net zoals laatst met Facebook en Whatsapp. Dat is dan wel in een heel andere richting maar evenzogoed, mij verbaast niets meer tegenwoordig.

[bytemaster460]

Ja klopt, fabrikanten kunnen de datumcomponent zodanig verweven hebben dat het hele apparaat niet meer functioneert als de datum niet meer klopt. Er zijn ook veel navigatie-apparaten die alleen met de tijd, of tijd, dag en maand werken. Die hebben er geen last van.

[martindekker]

Wel lekker op tijd gelukkig.

[effem]

Tja dat ligt aan tweakers, Zdnet en The Register hadden dit "nieuwtje" al 4 dagen geleden.
En het staat ook in de changelog van gpsd 3.23 van 6 aug:
Don't compute wrong GPS rollover after 2021-10-23.