Schrikkeljaar bug? Gewon een snelle gecodeerde oplossing voor datums, Werkt toch dit jaar, volgend jaar nieuwe kansen.

Allemaal problemen die je met cash niet hebt. Dat werkt ook gewoon in een schrikkeljaar.

Hadden ze dit niet 4 jaar geleden al kunnen bedenken dan?

Bij de aanbesteding waren ze wel lekker goedkoop.

Ja, dan kun je gewoon iedere dag beroofd worden.

Echt, ik zou die cash freaks graag een paar weken nachtdienst in een tankstation ergens laten draaien.

Het schrikkelsysteem is ingevoerd door Julius Caesar .
(voor de moderne scholier : Romein , ca 40 voor Christus)

Met een verbetering ingevoerd door Paus Gregorius , 1582 in de meeste landen.

De Gregoriaanse verbetering op de Juliaanse kalender was het meest recent relevant in 2000 .

Oftewel - het is niet dat de developers er pas vier jaar geleden mee geconfronteerd werden...

Alsof je niet gewoon aan de ATM kan beroofd worden voor veel meer, of dat ze je pas stelen en contactloos net onder 50 euro besteden zofat ze geen pin hoeven ingeven.

Ik zou jou gezicht wel eens willen zien als ze je een gedetaileerd rapport geven van alles waar je je geld aan uit geeft, inclusief de plaatsen en tijdstippen.

Zeker moderne webdevelopers. In Kernighan en Ritchie uit de jaren 1980 stond al de 1-regelige test op een schrikkeljaar:

if ((year % 4 == 0 && year % 100 != 0) || year % 400 == 0) printf("%d is a leap year\n", year);

Zeker te moeilijk voor de meeste Javascript code copy pasters.

Verschrikkelijke typo:

Tal van Nieuw-Zeelandse tankstation waren vandaag door een schrikkeljaarbug

;-)

Zoiets zal het inderdaad zijn, maar als je zoiets schrijft, let dan even op je eigen taalfouten. Als dit programmacode was geweest had je het niet gecompileerd of geïnterpreteerd gekregen, en in dat opzicht zijn de ontwikkelaars die voor deze bug verantwoordelijk zijn toch verder gekomen. ;-)

Het ging om betaalterminals op (vooral) onbemande tankstations, uitsluitend de terminals die buiten op de pompen zitten. Daar voeren mensen geen datum in en daar hoeft dus ook geen datuminvoer van die mensen gevalideerd te worden. Het is speculeren hoe dat nou precies misging, maar een scenario dat ik kan bedenken is dat de terminal een bericht aan de backend stuurt dat een datum en tijd bevat, en door geen rekening te houden met een schrikkeljaar 1 maart in plaats van 29 februari produceert, waarop de backend reageert met "kan niet kloppen" en het bericht niet accepteert.

Hoe dan ook, toen ik in 1985 als COBOL-programmeur mijn IT-loopbaan begon was dit inderdaad gesneden koek, en tegenwoordig zijn voor alle talen volop libraries beschikbaar dit dit soort shit voor je afhandelen. Bij enigszins moderne talen is het onderdeel van de standaardbibliotheek van de taal. Het lijkt een hele prestatie te zijn om het nog fout te doen.

Maar er rollen natuurlijk zat onervaren mensen het vak in (iedereen begint onervaren); je hebt tegenwoordig IT-opleidingen op MBO-niveau voor dingen die vroeger HBO- of universitair niveau hadden (waarbij ik moet aantekenen dat ik mensen met niet meer dan MAVO heb meegemaakt die het geweldig deden en academici die er niets van bakten); er zijn volop bedrijven die voor een dubbeltje op de eerste rang willen zitten en in plaats van te investeren in de kennis van hun medewerkers ze voorzien van een onmogelijke werkdruk; en dan is de IT in meerdere opzichten ook nog eens dramatisch veel complexer dan die vroeger was. Het verbaast me met andere woorden totaal niet dat allerlei dingen lang niet meer zo goed gaan als ze 40 jaar geleden gingen. Helaas.

Als je 'gewoon aan ATM' telkens cash gaat halen is dat een risico ja.
En als je pas gestolen wordt is het maximale verlies 50 euro - wat dan ook nog vaak vergoed wordt door de bank.

Heel veel minder opbrengst dan de dagopbrengst van een tankstation in de cash-tijd.

Die werden toen met regelmaat overvallen, net als bankkantoren.

Maar duidelijk weer een "ikke ikke denker" - ikke wil cash, ik denk alleen aan mijn persoonlijke risico en niet aan dat van de mensen die voor mijn voorkeur achter een dik gevulde kassa moeten staan.
Want ikke is ITer en ikke werkt lekker achter een scherm veilig thuis.


Kom maar op.
Beduidend minder traumatisch dan een 9mm in je giechel .

Als je gezamenlijk MEER dan 50 euro pint moet je ook jouw pinnummer invoeren.

Alleen achter een toetsenbord zijn ze een kanjer.

Vorig jaar horloge gekocht, bleek te komen uit China. Herkent tot mijn verbazing geen schrikkeljaar 2024.

Om dit te verhelpen moet je donderdag 28 februari 2024 instellen (ipv donderdag 29 februari) opdat je vrijdag 1 maart ziet verschijnen: anders staat de datum het hele jaar door fout, zo bleek na controle.

Dus ook de schrikkeleeuwjaren zullen niet goed worden afgebeeld (Schrikkeleeuwjaren zijn eeuwjaren die in de Gregoriaanse kalender door 400 deelbaar zijn). Het zijn niet alleen tankstations die er last van hebben zo blijkt.

Wie had het ook weer over een millennium bug in horloges?

Jij snapt hem. Dat houd in dat je elke ca 4,12 jaar een schrikkeljaar hebt. (elk 400/97 om precies te zijn) En dus niet elke 4 jaar, zoals vandaag in mijn krant beweerd werd.

Elke vier jaar is een heel aardige benadering - en bovenstaande regel willen uitschrijven in een krantenbericht is gewoon zinloos pendant doenerij.

Het duurt nog 76 jaar voordat je weer moet nadenken over 'elke 4 jaar' - als het geen echte jonkies zijn gaan de posters hier dat niet meemaken. En nog 376 jaar voordat de laatste correctie relevant is.

Rondom 1999/2000 werd natuurlijk de eeuwjaar tenzij deelbaar door 400 wel uitgelegd, want dat was de recente - en enige in de tijd van automatisering - waarin de volledige gregoriaanse regel van toepassing was.