Schrikkeljaarfout in software legt tankstations Nieuw-Zeeland plat

2000 zou ook geen schrikkeljaar worden oorspronkelijk, maar is het wel geworden. Kan ook met 2100.

We krijgen eerst nog het 2038 probleem, al denk ik dat dat wel met een sisser afloopt. Zal ongetwijfeld het een en ander aan legacy omvallen.

https://en.wikipedia.org/wiki/Year_2038_problem

UTC met tijdzone bestaat sowieso al niet. Je bedoeld denk ik een datum/tijd zonder zone aanduiding want UTC is een datum/tijd met zone. (Zone Zulu) maar ook, notatie is weer want anders dan hoe het geïmplementeerd is, dat gebeurt helaas nog vaak met een 32 bit doen dat zou sowieso een tijd zijn tov epoch. Nee, imho de ont ontwikkelaar heeft ergens eens api niet goed begrepen of heeft lopen goochelen met tijden.

Als die omzetting niet goed gaat, dan zou je verwachten dat het elke dag fout gaat.

Het heeft ook niets met tijdzones te maken, lijkt me. Het is een NZ systeem, en daar hebben ze bij mijn weten maar 1 tijdzone. Het hele systeem kan dus worden beperkt tot lokale tijd, dus tijdzones volledig negeren.

Daarom altijd werken met interne notatie en het formatteren op het allerlaatste moment.

Er zijn anders genoeg libraries met problemen geweest . Ik heb hier met enige regelmaat een artikel gelezen over iPhones met problemen rond de jaarwisseling.

Mijn persoonlijke pet peeve is een Windows C library functie die een UNIX timestamp converteert naar een Windows FILETIME timestamp.

Een UNIX timestamp is het aantal seconden sinds 1 januari 1970 0:00 UTC.
Een FILETIME timestamp is het aantal 100-nanoseconden sinds 1 januari 1601 0:00 UTC.

Conversie ertussen zou dus niet zo moeilijk moeten zijn: gewoon een lineaire transformatie. Alsof je van graden Celcius naar graden Fahrenheit gaat oid. Dus je telt er eerst het aantal seconden tussen die twee epochs bij, en daarna vermenigvuldig je met 10.000.000. Kind kan de was doen,.

Maar wat deed de library functie? Hij pakte eerst de datum en tijdrepresentatie van de UNIX timestamp in de lokale tijdzone, en zette dat vervolgens weer om naar een FILETIME. Alleen pakte die eerste conversie de huidige daylight savings tijd mee (ook al was de timestamp zelf in een niet DST-periode), en de tweede functie hield daar wel rekening mee. Of misschien was het precies andersom, ik weet het niet meer. Met als gevolg dat alle wintertijd timestamps tijdens de zomertijd er een uur naast zaten

[Reactie gewijzigd door .oisyn op 25 juli 2024 00:30]

Dat kan niet altijd, even effe ergens een library pakken.
- soms schrijf je in een taal waarbij er geen libraries beschikbaar zijn. Of het niet gewenst is.

Maar over het algemeen heb je gelijk, niet je eigen brakke implementatie schrijven als het niet nodig is en andere al hun hoofd erover gebroken hebben en dit duidelijk stabieler is.

[Reactie gewijzigd door Zezura op 25 juli 2024 00:30]

Morgen is het probleem waarschijnlijk ook verholpen. Tenzij het een verschuifprobleem is en je ook na de schrikkeldag niet in sync bent.

Juist bij Tweakers zou je verwachten dat er ook iets meer details bij staan of zelfs een gedetailleerde analyse wat er precies fout ging. Steek je er misschien nog wat van op of zo.

Dit filmpje was het eerste waar ik aan dacht toen ik dit bericht las! Blijkbaar zit dit nog steeds niet ingebakken bij programmeurs!

Kan zeker, maar anderzijds kan er ook een significante hoeveelheid benzine, diesel, gas en wie weet waterstof en stroom worden verkocht in 6 uur, bij misschien wel honderden pompstations. Alle pompstations die ik ken zijn al voorzien van een optie om software op afstand bij te werken, dus dat hoeft op nauwelijks iets extra te kosten. Daarnaast is er zoiets als reputatie. Ook als een update financieel niets oplevert, wil je toch voorkomen dat klanten een slechte indruk van je krijgen. Misschien is dat de opdrachtgever wel een dagje extra debuggen waard.

bijzonder toch.. Het is niet alsof de schrikkeldag een nieuw fenomeen is.
ik vrees dat uitbesteding van de verantwoordelijkheid en de uitvoering ten grondslag ligt.
"If you pay peanuts, you'll get monkeys"