U herinnert zich waarschijnlijk de paniek rond Y2K. De media voorspelden een mondiale ineenstorting toen de klok het jaar 2000 sloeg. Maar hoewel veel oude systemen destijds werden hersteld, tikt er nog steeds een andere timer op de achtergrond van een groot deel van het moderne internet. Het wordt het Jaar 2038-probleem genoemd. En het is geworteld in de manier waarop C-programmeertalen met tijd omgaan.
De meeste mensen gaan ervan uit dat het om tweecijferige jaren gaat, zoals Y2K. Dat is het niet. Het kernprobleem ligt dieper in de code. Specifiek, hoe C-programma’s datumgegevens opslaan.
De 32-bits limiet
Hier is de technische realiteit. De standaardtijdbibliotheek in C gebruikt een geheel getal van 4 bytes met teken om de tijd bij te houden. Dat zijn 32 bits. Dit formaat definieert “tijdperktijd” als beginnend op 1 januari 1970, om 12:00:00 uur UTC. Elke seconde na dat moment wordt opgeslagen als een eenvoudig getal.
Het tijdstempel ‘919642718’ vertegenwoordigt bijvoorbeeld 919 miljoen seconden voorbij het tijdperk. Dat landt op 21 februari 1999. Het is handig omdat het aftrekken van de ene tijdstempel van de andere u de exacte seconden tussen twee gebeurtenissen geeft. Bibliotheken zetten die seconden vervolgens om in minuten, uren of jaren.
Maar er is een hard plafond.
Een 32-bits geheel getal met teken heeft een maximale waarde van 2.147.483.647. Zodra de teller na 1 januari 1970 nul seconden bereikt, draait hij om.
Die rollover vindt plaats op 19 januari 2038.
Na die datum loopt het gehele getal over. Het verandert in een negatief getal. Voor een systeem dat op dit formaat vertrouwt, is die negatieve waarde een ongeldige datum. Het is in feite een fout in de matrix voor software die niet is bijgewerkt.
Waarom dit gemakkelijker is dan het millennium
Het goede nieuws? Dit oplossen is niet zo rommelig als de mainframe-nachtmerries van eind jaren negentig.
In Y2K standaardiseerden veel systemen niet hoe ze datums opsloegen. Sommigen gebruikten MM-DD-JJ. Anderen gebruikten JJ-MM-DD. Het ontbreken van een universeel formaat betekende dat ontwikkelaars in elke applicatie code moesten opzoeken en de datumlogica handmatig moesten wijzigen.
Het jaar 2038-probleem is schoner.
De standaardtijdbibliotheek omvat het volledige tijdregistratieproces. Het definieert zijn eigen typen en functies. Goed geschreven programma’s kunnen dus eenvoudig opnieuw worden gecompileerd. Ingenieurs hoeven alleen maar de bibliotheek te vervangen door een versie die een grotere bytegrootte gebruikt.
Als u bijvoorbeeld van een geheel getal van 4 bytes naar een geheel getal van 8 bytes gaat, wordt het bereik aanzienlijk vergroot. Een geheel getal van 8 bytes kan tot ver na 2038 tellen zonder dat het overloopt. Het is een software-update. Geen hardwarevervanging. Geen herschrijving van de code. Een bibliotheekruil.
Windows en Mac: verschillende timers, verschillende problemen
Niet elk systeem gebruikt het 32-bits C-formaat. Verschillende besturingssystemen hebben hun eigen eigenaardigheden.
Windows NT gebruikt bijvoorbeeld een 64-bits geheel getal. Het houdt de tijd bij in stappen van 100 nanoseconden. Maar het begint te tellen vanaf 1 januari 1601, niet vanaf 1970. Dit schuift de overstroomdatum veel verder naar buiten. Windows zal waarschijnlijk rond het jaar 2184 zijn limiet bereiken.
Apple heeft een andere aanpak gekozen. Volgens de eigen documentatie van Apple is macOS zo gestructureerd dat het geldig blijft tot het jaar 29.940. Dat is ongeveer 27.000 jaar vanaf nu. Dus als u een Mac gebruikt, hoeft u zich geen zorgen te maken dat uw agenda in 2038 crasht.
Wie loopt er nog meer gevaar?
Op Unix gebaseerde systemen vormen de voornaamste zorg. Maar ze zijn niet de enigen.
Ook embedded systemen zijn kwetsbaar. Veel IoT-apparaten, industriële controllers en oudere databaseservers vertrouwen op hetzelfde 32-bits tijdformaat. Als ze niet zijn bijgewerkt, zullen ze na 19 januari 2038 datums verkeerd gaan interpreteren.
Oplossingen voor de korte termijn kunnen het patchen van software inhouden om negatieve tijdwaarden correct te verwerken. Maar dat is een verband. De permanente oplossing vereist een upgrade naar een 64-bits tijdformaat.
De vraag is niet of de code zal breken. Het gaat erom of de systemen die die code uitvoeren, zullen worden bijgewerkt voordat de klok om is.
Het grootste deel van de infrastructuur waarop we vertrouwen, beweegt zich al in de richting van 64-bit tijdwaarneming. Maar niet alles is zo. Oude servers. Oudere industriële apparatuur. Een beetje ingebedde logica. Dat zijn de zwakke schakels.
Wanneer 19 januari 2038 aanbreekt, zal de klok zijn limiet bereiken. Voor sommige systemen zal het een non-event zijn. Voor anderen zal het een harde stop zijn. Er zal niet veel tijd zijn om de code te patchen als je tot het laatste moment wacht.
