Het jaar 2038-probleem: de grens van Unix-tijdstempels
De tijd stopt niet. Eén manier om tijd op te slaan bereikt zijn grootste positieve getal.
Een teller in een eindig vak
Unix-tijd telt seconden vanaf 1 januari 1970 om 00:00:00 UTC, zonder schrikkelseconden mee te tellen. Een getekend 32-bits geheel getal kan maximaal 2.147.483.647 bevatten. Als Unix-seconden is dat 19 januari 2038 om 03:14:07 UTC. Een seconde later past het getal niet meer in die 32-bitsnotatie. De datum is gewoon; de opslaggrens veroorzaakt het probleem.
Niet elke computer heeft die grens
Het probleem zit in systemen, bestandsformaten, protocollen of databases die deze beperkte notatie gebruiken. Bredere tijdtypen kunnen latere datums weergeven. Een moderne app kan wel gegevens met een oudere component uitwisselen; alleen de zichtbare klok controleren is niet genoeg. Een te grote waarde kan worden geweigerd, afgekapt of verkeerd geïnterpreteerd. Niet elk apparaat springt naar 1901 en het internet stopt niet simpelweg.
Een tweede valkuil is duizend keer kleiner
Seconden en milliseconden zijn verschillende eenheden. Voer 2.147.483.647 in als milliseconden en je belandt in januari 1970, niet 2038. De eenheid raden aan het aantal cijfers is onbetrouwbaar, vooral bij oude datums of kleine waarden. Onze tool vraagt de eenheid expliciet. Noteer bij foutopsporing waarde, eenheid en verwacht UTC-resultaat. Die kleine gewoonte voorkomt verrassend veel datumfouten.
Verken de grens veilig
Probeer 2147483647 en 2147483648 in onze converter met seconden geselecteerd. De resultaten liggen één seconde uit elkaar, beide in 2038, omdat deze browsertool niet beperkt is tot getekende 32-bits Unix-seconden. Dat bewijst deze berekening, niet de gereedheid van al je systemen. Test opslag en interfaces aan beide kanten van de grens, inclusief opslaan en teruglezen. Een correcte weergave is slechts één onderdeel.
Test je intuïtie
Bronnen en verder lezen
Originele uitleg met uitgewerkte voorbeelden. Bronlinks verwijzen naar de onderliggende normen en documentatie.