Een klok die eigenlijk maar één getal is
Bijna elk apparaat dat je vandaag hebt aangeraakt, is het eens over één getal. Niet over de tijd in jouw stad, niet over je kalender, niet over je tijdzone: één geheel getal dat de seconden telt sinds middernacht op 1 januari 1970 in UTC. Dat getal heet Unix-tijd, en het is op dit moment een getal van tien cijfers dat elke seconde met één toeneemt.
Het is een elegant idee. In plaats van „dinsdag, 15 uur in Amsterdam“ op te slaan, met al zijn menselijke regels, onthoudt een machine iets als 1771200000. Eén moment, één getal, zonder dubbelzinnigheid. Je server in Frankfurt, je telefoon in Antwerpen en een sensor in een fabriek zijn het erover eens, ook al tonen hun wandklokken iets anders. Je ziet het huidige getal en de leesbare datum in onze Unix-timestamp-converter.
Het probleem is dat een getal dat alleen maar stijgt, ooit zonder ruimte komt te zitten. En voor een heel concrete, heel gangbare manier om Unix-tijd op te slaan weten we precies wanneer: 03:14:07 UTC op 19 januari 2038.
Waarom 1970
Het startpunt, het „epoch“ genoemd, is 1 januari 1970. Er is niets kosmisch aan. Begin jaren zeventig hadden de ingenieurs die Unix bij Bell Labs bouwden een handige, recente nuldatum nodig, en een rond begin van een decennium voldeed prima. Momenten vóór 1970 worden simpelweg met negatieve getallen weergegeven.
Die bescheiden beslissing verspreidde zich over de hele digitale wereld. Vandaag zit Unix-tijd in databases, netwerkprotocollen, bestandssystemen, logboeken en de firmware van apparaten die de makers nooit hadden voorzien. De begindatum doet er bijna nooit toe. Wat ertoe doet, is hoeveel ruimte de computer heeft gereserveerd om het getal te bewaren.
Het getal dat opraakt
Decennialang was de gebruikelijke manier om Unix-tijd op te slaan een 32-bits geheel getal met teken. „Met teken“ betekent dat één bit positieve van negatieve getallen onderscheidt, wat een maximumwaarde van 2.147.483.647 overlaat. Zo veel seconden kan die teller bevatten.
Tel 2.147.483.647 seconden op bij middernacht in 1970 en je komt uit op dinsdag 19 januari 2038, 03:14:07 UTC. Eén seconde later loopt de teller over. Omdat het tekenbit omklapt, springt het getal niet naar 2.147.483.648: het wordt negatief en belandt op 13 december 1901. Denk aan de kilometerteller van een oude auto die van 999999 naar 000000 gaat, alleen duikt de auto hier ineens op in de vorige eeuw.
Eén detail bekoort liefhebbers: de grenstijd is 03:14:07, oftewel 3, 14, 7, een knipoog naar de eerste cijfers van pi. Unix-tijd kent meerdere van zulke gevierde momenten, en dat van 2038 is gewoon het eerste dat dingen breekt in plaats van een T-shirt te sieren.
| Unix-tijdwaarde | Moment (UTC) | Waarom men het onthoudt |
|---|---|---|
| 0 | 1 januari 1970, 00:00:00 | Het epoch: de seconde nul waar alles aan hangt. |
| 1.000.000.000 | 9 september 2001, 01:46:40 | Het „Unix-billennium“, gevierd door programmeurs. |
| 1.234.567.890 | 13 februari 2009, 23:31:30 | Een telling met geordende cijfers; er waren echte feestjes. |
| 2.147.483.647 | 19 januari 2038, 03:14:07 | Het plafond van 32 bits met teken: het jaar-2038-probleem. |
Waarom dit niet de millenniumbug in een nieuw jasje is
Het is verleidelijk om dit naast de millenniumbug (Y2K) te leggen en door te gaan. Maar het zijn verschillende problemen. De millenniumbug was een menselijke afspraak: software bewaarde jaartallen met twee cijfers, dus „99“ werd „00“ en de computer wist niet meer of het 1900 of 2000 was. Het was een formaatprobleem, vooral in de laag waar mensen datums lezen en schrijven.
Het jaar 2038 zit dieper. Het gaat niet over hoe een datum wordt getoond, maar over de fundamentele eenheid waarmee de machine de tijd telt. Je lost het niet op door jaartallen met vier cijfers op het scherm te zetten; je moet de houder vergroten die het getal zelf bewaart.
| Jaar 2000 | Jaar 2038 | |
|---|---|---|
| Kern van het probleem | Jaartallen opgeslagen met twee cijfers | Seconden opgeslagen in 32 bits met teken |
| Getroffen laag | Formaat en presentatie | Het datatype en de onderliggende opslag |
| Typische oplossing | Jaartallen met vier cijfers gebruiken | 64-bits gehele getallen voor de tijd gebruiken |
| Lastiger te veranderen | Applicatielogica | Formaten op schijf, protocollen en oude apparaten |
Het vreemde: 2038 breekt nu al dingen
De subtiele denkfout is dit voor een verre afgrond houden. Dat is het niet. Elk systeem dat datums naar de toekomst berekent, passeert de grens van 2038 vandaag al. Een hypotheek van dertig jaar afgesloten in 2026 berekent vervaldata na 2038. Een certificaat, een garantie, een polis of een langlopend abonnement doet rekenwerk dat de grens ruim vóór de datum zelf overschrijdt.
Daarom zijn er al losse storingen geweest: een systeem dat „over twintig jaar“ in een 32-bits getal wil weergeven, krijgt ineens een datum uit 1901, een negatieve termijn of een onverklaarbare fout. Het jaar 2038 wacht niet op 2038. Het komt eerder voor elke code die ver genoeg vooruitkijkt.
Waar het echt pijn doet, en waar niet
Het goede nieuws: je laptop en je telefoon zijn vrijwel zeker veilig. Moderne 64-bits besturingssystemen slaan Unix-tijd allang op in 64-bits gehele getallen. JavaScript telt de tijd in milliseconden binnen een drijvendekommagetal dat pas over honderdduizenden jaren een probleem krijgt. Python gebruikt gehele getallen met onbeperkte precisie. Voor de meeste actuele software is 2038 een voetnoot.
Het gevaar leeft elders: in 32-bits apparaten met een lang leven en zeldzame updates. Routers, industriële regelaars, slimme meters, medische apparatuur, autoregelunits en sensoren die je twintig of dertig jaar installeert en vergeet. En in formaten: vaste 32-bits datumvelden binnen bestanden, netwerkprotocollen, oude bestandssystemen en lang geleden ontworpen databasekolommen. De processor kan klaar zijn, maar gegevens die in het oude formaat zijn opgeslagen, repareren zichzelf niet.
De oplossing is saai, en dat is goed
De belangrijkste oplossing is simpel te beschrijven: bewaar de tijd in een 64-bits geheel getal met teken in plaats van 32. Dat rekt het bereik van de teller op tot zo'n 292 miljard jaar, ver voorbij de leeftijd van het universum. Je hoeft niets nieuws te bedenken; je geeft het getal alleen meer ruimte.
Veel van dat werk is al gedaan. De Linux-kernel besteedde jaren aan het 2038-veilig maken van zelfs 32-bits platforms, de standaardbibliotheken werden bijgewerkt en de BSD's deden hetzelfde. Het moeilijke zijn niet de processoren, maar de rustende gegevens: bestandsformaten, protocollen en oude apparaten migreren zonder alles te breken wat er al van afhangt. Het is stil, onglamoureus en diep nuttig werk; precies wat goede infrastructuurtechniek hoort te zijn.
Wat je kunt doen
- Controleer of je taal of database de tijd in 32 of 64 bits opslaat, vooral op oude systemen.
- Zoek elke plek waar je datums jaren of decennia vooruit berekent; die code passeert 2038 vandaag al.
- Bekijk ingebedde apparaten en firmware met een lang leven, waar updates zeldzaam zijn.
- Behandel datums op schijf en in protocollen als contracten: de grootte van een tijdveld wijzigen raakt alles wat het leest.
- Test de systeemklok in een gecontroleerde omgeving voorbij 2038 om te zien wat breekt voordat het ertoe doet.
Een getal dat het waard is om in de gaten te houden
Het jaar-2038-probleem herinnert er mooi aan dat digitale tijd een menselijke keuze is, geen natuurwet. We besloten seconden te tellen, besloten in 1970 te beginnen en besloten hoeveel bits we eraan zouden besteden. Elk van die beslissingen was redelijk toen ze werd genomen, en elk laat een spoor na dat decennia meegaat.
Ondertussen klimt de teller stil verder, een seconde per seconde. Ben je nieuwsgierig, bekijk dan het huidige getal in onze Unix-timestamp-converter, bevestig de datum van vandaag of bereken de tijd tot een toekomstige datum met de deadlinecalculator. En als tijdfouten die vandaag al software breken je interesseren, dan zet onze gids over de meest voorkomende datum- en tijdbugs het verhaal voort.