Wat is een Unix-tijdstempel?

Een Unix-tijdstempel is één enkel getal: het aantal seconden dat is verstreken sinds het Unix-tijdperk, gedefinieerd als 00:00:00 UTC op 1 januari 1970. Dat is alles. Geen tijdzone, geen datumreeks, geen maandnamen — gewoon een geheel getal dat elke seconde met één eenheid oploopt.

Omdat het tijdperk vast en universeel is, betekent een tijdstempel zoals 1700000000 exact hetzelfde moment overal op aarde. Een server in Tokio en een laptop in Chicago zullen het erover eens zijn dat het verwijst naar 14 november 2023 om 22:13:20 UTC. De lokale weergave verschilt per tijdzone, maar het onderliggende getal verandert nooit.

Een bewuste vereenvoudiging: Unix-tijd negeert schrikkelseconden. Het gaat ervan uit dat elke dag precies 86.400 seconden duurt, wat astronomisch niet helemaal klopt, maar de rekenkunde wel schoon houdt. Hieronder meer daarover.

Waarom ingenieurs er dol op zijn

Tijdstempels zijn overal in software — bestandswijzigingstijden, databaserecords, API-reacties, JWT-vervalvelden, logregels — en dat is niet voor niets:

• Het is één enkele waarde. Eén geheel getal slaat een volledige datum en tijd op. Geen parsing, geen dubbelzinnigheid over MM/DD versus DD/MM.
• Ze zijn tijdzone-agnostisch. Het getal is altijd UTC. Je converteert alleen naar lokale tijd wanneer je het aan een mens toont.
• Ze vergelijken en sorteren moeiteloos. Welke gebeurtenis kwam eerst? Het kleinere gehele getal. Tijdsduur tussen twee gebeurtenissen? Trek ze van elkaar af; het antwoord is in seconden.
• Ze slaan compact op. Een enkel 4- of 8-byte geheel getal versus een opgemaakte tekenreeks.

Dit is waarom zoveel infrastructuur onder de motorkap in epoch-seconden spreekt, zelfs als de interface je een vriendelijke 2026-07-23 laat zien. Als je tussen de twee representaties wilt bewegen, doet een Unix tijdstempel converter de vertaling in beide richtingen.

Een tijdstempel lezen: een uitgewerkt voorbeeld

Neem het tijdstempel 1000000000 — een beroemde, omdat het live op tv oversloeg onder Unix-liefhebbers.

Om het handmatig te lezen, deel je de seconden op in grotere eenheden. Grofweg is 1.000.000.000 seconden ongeveer 31,7 jaar (een jaar is ~31.556.952 seconden). Tel dat op bij het tijdperk van 1970 en je komt uit in 2001. Het precieze moment is 9 september 2001, 01:46:40 UTC.

Je doet deze rekenkunde zelden handmatig — elke taal heeft een ingebouwde functie. In Python:

```python from datetime import datetime, timezone datetime.fromtimestamp(1000000000, tz=timezone.utc)

2001-09-09 01:46:40+00:00

```

Het belangrijkste punt: conversie is altijd verankerd aan UTC. De functie zet een ruwe telling van seconden om in een kalenderdatum door vooruit te gaan vanaf het tijdperk. Als je in plaats daarvan lokale tijd wilt, pas je een tijdzone-offset toe na de UTC-conversie — het tijdstempel zelf bevat geen zone-informatie.

Het jaar 2038-probleem

Hier wordt het verhaal interessant — en waar veel anderszins goed gebouwde systemen een tikkende klok in zich hebben.

Decennialang was het C-standaardtype dat wordt gebruikt om Unix-tijd vast te houden, time_t, gebruikelijk een signed 32-bit integer. Een signed 32-bit integer kan waarden vertegenwoordigen van −2.147.483.648 tot 2.147.483.647. Die bovengrens is het probleem.

Als we seconden tellen vanaf het tijdperk van 1970, wordt de waarde 2.147.483.647 bereikt op 03:14:07 UTC op 19 januari 2038. Eén seconde later moet de teller 2.147.483.648 worden — maar dat getal past niet in een signed 32-bit integer. In plaats van door te gaan met oplopen, overlopen de bits en wikkelen ze om naar de meest negatieve waarde, −2.147.483.648.

Een negatief tijdstempel wordt geïnterpreteerd als een tijd vóór het tijdperk. Dus de klok stopt niet alleen — hij springt terug naar 13 december 1901. Elk systeem dat zijn 32-bit time_t vertrouwde, gelooft plotseling dat het begin twintigste eeuw is.

Dit wordt vaak de Y2K38-bug of de Unix Millennium Bug genoemd, en structureel is het dezelfde soort overflow met vaste breedte die de angst voor het jaar 2000 veroorzaakte — alleen verder weg en geworteld in binaire integer-limieten in plaats van tweecijferige jaren.

Waar het echt bijt

Moderne 64-bit desktops en servers zijn jaren geleden grotendeels gerepareerd. Het risico concentreert zich op plaatsen die moeilijk te updaten zijn:

• Embedded en industriële systemen. Routers, controllers, medische apparaten, automotive ECU's en IoT-hardware die zijn geleverd met 32-bit time_t en mogelijk 20+ jaar ongemoeid blijven draaien. Veel apparaten die vandaag worden geïmplementeerd, zullen in 2038 nog in gebruik zijn.
• Legacy C-code. Applicaties gecompileerd tegen een oude time_t-definitie, vooral waar het type in schijf-formaten of netwerkprotocollen is geslopen.
• Oude databases en bestandssystemen. Opslagformaten die tijdstempels in 32-bit velden hebben gepropt. Sommige oudere systemen vertonen al symptomen bij het verwerken van verre toekomstdatums — denk aan een hypotheek van 20 jaar of een certificaatvervaldatum die voorbij 2038 reikt.

De faalmodus is niet altijd een dramatische crash. Soms is het een subtiel verkeerd berekende datum: een verlopen token dat als geldig wordt gelezen, een sorteervolgorde die omkeert, een geplande taak die in 1901 wordt geactiveerd.

De oplossing: 64-bit tijd

De remedie is in principe eenvoudig — verbreed time_t naar 64 bits. Een signed 64-bit integer kan seconden tellen tot ver voorbij elke praktische horizon: het overflow-punt ligt ongeveer 292 miljard jaar in de toekomst, ruim voorbij de verwachte levensduur van de zon.

De meeste huidige besturingssystemen hebben deze stap al gezet. 64-bit Linux gebruikt een 64-bit time_t; zelfs 32-bit Linux heeft de afgelopen jaren 64-bit tijdondersteuning gekregen in de kernel en glibc. Het moeilijke deel is niet de oplossing zelf — het is het vinden en herbouwen van elk laatste stukje firmware, elk opgeslagen formaat en elke third-party binary die nog steeds 32 bits aanneemt. Dat auditwerk is het echte 2038-project.

Hoe schrikkelseconden erin passen

Astronomische tijd en atoomtijd lopen iets uit elkaar, dus voegt officiële UTC af en toe een schrikkelseconde in om klokken in lijn te houden met de rotatie van de aarde. Unix-tijd doet alsof deze niet bestaan — het hardcodeert 86.400 seconden per dag.

Wanneer een schrikkelseconde optreedt, "smeren" systemen deze doorgaans uit — ze spreiden de extra seconde over een venster (Google populariseerde een 24-uurs smear) zodat geen enkele klok ooit de onmogelijke 23:59:60 hoeft te tonen. Het gevolg: Unix-tijdstempels blijven soepel en monotoon, ten koste van een fractie van een seconde afwijking van strikte UTC tijdens een smear. Voor vrijwel alle software is dit precies de afweging die je wilt. De 2038-overflow is een integer-breedte probleem; schrikkelseconden zijn een aparte, veel kleinere definitie eigenaardigheid — verwar ze niet.

Belangrijkste punten

• Een Unix-tijdstempel is seconden sinds 00:00:00 UTC op 1 januari 1970, schrikkelseconden genegeerd.
• Het is één enkel, tijdzone-agnostisch geheel getal — gemakkelijk op te slaan, te vergelijken en te sorteren.
• Conversie is altijd relatief aan UTC; lokale tijd wordt achteraf toegepast.
• Signed 32-bit time_t overloopt op 03:14:07 UTC op 19 januari 2038, wikkelt om naar een negatieve waarde en springt naar 1901.
• De oplossing is 64-bit time_t; de inspanning is het auditen van embedded en legacy systemen.

Wil je het in actie zien? Plak een epoch-waarde in de Unix tijdstempel converter om het als een menselijke datum te lezen — of ga de andere kant op en zet een datum om in zijn tijdstempel.

Veelgestelde vragen

Is een Unix-tijdstempel in seconden of milliseconden?

Klassieke Unix-tijd is in seconden. JavaScript en veel web-API's gebruiken echter milliseconden sinds het tijdperk, dus een waarde zoals 1700000000000 is 1.000× groter. Een snelle aanwijzing: een op seconden gebaseerd tijdstempel voor een recente datum heeft 10 cijfers; een op milliseconden gebaseerde heeft er 13. Bij twijfel, controleer de grootte voordat je converteert.

Zal het jaar 2038-probleem mijn telefoon of laptop laten crashen?

Bijna zeker niet. Moderne 64-bit besturingssystemen gebruiken al een 64-bit time_t, wat de overflow miljarden jaren naar buiten duwt. De echte blootstelling zit in langlevende embedded apparaten en oude software die nog steeds vertrouwt op 32-bit tijd en mogelijk niet wordt bijgewerkt vóór 2038.

Kan een Unix-tijdstempel negatief zijn?

Ja. Negatieve waarden vertegenwoordigen momenten vóór het tijdperk van 1970 — bijvoorbeeld -1 is 31 december 1969, 23:59:59 UTC. Dit is precies wat een 32-bit overflow produceert in 2038, daarom lijkt de klok terug te springen naar 1901.

Waarom negeert Unix-tijd schrikkelseconden?

Om de wiskunde eenvoudig en voorspelbaar te houden. Door elke dag als precies 86.400 seconden te behandelen, zijn tijdsduren gewoon aftrekken en blijven tijdstempels monotoon. De kleine mismatch met astronomische UTC wordt afgehandeld door de schrikkelseconde te "smeren", wat bijna alle applicaties verkiezen boven het omgaan met een 23:59:60-randgeval.

Hoe converteer ik een tijdstempel zonder code te schrijven?

Gebruik een online tool. De Unix tijdstempel converter accepteert een epoch-waarde en toont direct de overeenkomende UTC en lokale datum-tijd, en converteert ook kalenderdatums terug naar tijdstempels.