Overleven we 2038?

Het jaar 2000. Computers zouden spontaan exploderen omdat jaartallen, getrunceerd tot de laatste twee cijfers (1999 -> 99), in het jaar 2000 als 00 zouden worden geïnterpreteerd. Het spontane exploderen van de wereld is uiteindelijk toch niet gebeurd, en we leven allemaal nog.

Maar hoe zit het dan met 2038? Het probleem is vergelijkbaar met het beruchte Y2K, maar wellicht vele malen erger. Alle Unix systemen (bijv. Mac OS, Linux), en ook veel niet-Unix systemen, houden de datum van vandaag bij op een wat bijzondere manier: ze tellen het aantal seconden dat verstreken is sinds 1 januari 1970, 00:00 UTC. Dit heet ook wel de Unix Epoch.

De Unix Epoch wordt gebruikelijk opgeslagen als 32-bit integer, een geheel getal bestaande uit 32 bits, dus 32 plaatsen die een nul of een kunnen zijn. De eerste plaats geeft aan of het getal negatief of positief is. De andere 31 bits geven het echte getal aan. Je hebt dus een minimumwaarde van -(2^31) en een maximumwaarde van (2^31) -1. De -1 omdat je begint vanaf 0 bij een positief integer, en vanaf -1 bij een negatief integer (anders zou je 0 dubbel tellen). Als je de minimum- of maximumwaarde overschrijdt dan krijg je een overflow: 01111111 11111111 11111111 11111111 (2^31 -1) wordt 10000000 00000000 00000000 00000000 ( -(2^31) )

Op 19 januari 2038, 03:14:07 UTC, zal een 32-bit Unix epoch zijn maximumwaarde bereiken en een seconde later overslaan naar -2147483648. 1 januari 1970 - 2147483648 seconden = 13 december 1901. Dus vanaf 19 januari 2038 worden datums door veel computers geïnterpreteerd als het aantal seconden na 13 december 1901, in plaats van 1 januari 1970.

Door slechte programmatuur kan een heel programma/systeem crashen. In computers, als een fout niet goed wordt afgehandeld, stopt het programma totdat het weer opnieuw wordt opgestart; dit gebeurt niet automatisch, tenzij er opzettelijk een systeem in plaats is gebracht om het programma te herstarten na een crash.

Oplossing: upgrade naar 64-bit. Een 64-bit Unix epoch zal pas ergens op 4 december in het jaar 292 277 026 596 overslaan. Dat geeft ons weer even wat spartelruimte.

Dat gaat echter niet altijd even makkelijk: embedded systems ("Geïntegreerde systemen", kleine chips, met simpele programmatuur, op bijvoorbeeld een moederbord) die tijd meten of verwerken zijn kwetsbaar omdat deze lastig te upgraden zijn naar 64-bit. Eigenlijk zijn ze onmogelijk te upgraden, tenzij de chip zelf 64-bit is. Dat is vaak niet het geval, want 32-bit is net wat minder complex om te fabriceren en voldoet aan eigenlijk alles voor de kleine functies van embedded systems. Minder moeite voor hetzelfde resultaat dus, behalve als het om Unix tijd gaat.

Android telefoons zijn ook kwetsbaar. Als je de datum op een android telefoon verzet naar 03:14:08 19/01/2038 crasht het apparaat en start het niet opnieuw op.

Setting the time and date to 03:14:08 19/01/2038 crashes the device and stops it from booting, effectively bricking it. This is on a ZTE Blade running 2.2, although I assume behaviour is the same across the board due to the year 2038 problem - Link

Als je de hele thread leest kom je erachter dat alle 32-bit android telefoons kwetsbaar zijn. Desondanks is de bug gesloten door Google, pure incompetentie. Maar eerlijk is eerlijk: waarschijnlijk zijn er geen 32-bit telefoons meer in 2038.

En zo zullen eigenlijk de meeste 32-bit dingen wel vervangen zijn door 64-bit dingen tegen die tijd. Hoop ik. Wie weet.

2019-04-20 in blog #2038 #32-bit #unix-epoch