Wat is een Unix-timestamp? Uitleg met voorbeelden
Een Unix-timestamp is het aantal seconden dat is verstreken sinds 1 januari 1970, 00:00:00 UTC. Dat moment heet de Unix-epoch, en elke seconde erna telt gewoon één op bij dat getal. Zie je in een database of een API-response een waarde als 1700000000 staan, dan kijk je naar een datum: in dit geval 14 november 2023.
Wat een Unix-timestamp precies is
Een Unix-timestamp drukt een exact tijdstip uit als één enkel geheel getal: het aantal seconden sinds de epoch. Geen dag, geen maand, geen tijdzone, gewoon een teller die sinds 1970 doortikt. Kolommen als created_at in een database, het exp-veld in een JWT-token en tijdstempels in logbestanden slaan tijd vaak op deze manier op, precies omdat het zo weinig ruimte inneemt en zo weinig ruimte laat voor misverstanden.
Het voordeel wordt duidelijk zodra je twee tijdstippen met elkaar moet vergelijken. Met een geformatteerde datumstring als “14-11-2023 22:13:20” moet je rekening houden met tijdzone, notatiewijze en soms zelfs taal voordat je kunt bepalen welk moment eerder was. Met Unix-timestamps is dat gewoon twee getallen met elkaar vergelijken: is 1700000000 kleiner dan 2000000000? Ja, dus dat eerste moment ligt eerder. Rekenen met tijd, zoals “hoeveel seconden zaten er tussen deze twee logregels” of “vervalt deze JWT over vijf minuten”, wordt daarmee simpele aftrekking in plaats van datumparsing.
Neem het exp-veld van een JWT-token als voorbeeld. Een server die moet controleren of een token nog geldig is, hoeft alleen het huidige moment als timestamp te nemen en dat te vergelijken met de waarde in exp. Is de huidige timestamp groter, dan is het token verlopen. Diezelfde controle met een geformatteerde datumstring zou eerst parsing, tijdzoneconversie en dan pas een vergelijking vereisen, met meer kans op fouten onderweg. Diezelfde logica geldt voor een created_at-kolom in een database: sorteren op recentste eerst is simpelweg sorteren op een getal, geen speciale datumfunctie nodig.
Praktijkvoorbeeld: timestamps lezen
De volgende tabel toont vijf timestamps en het exacte moment in UTC waarnaar ze verwijzen:
| Unix-timestamp (seconden) | Datum en tijd in UTC |
|---|---|
| 0 | 1 januari 1970 om 00:00:00 UTC (de epoch zelf) |
| 1000000000 | 9 september 2001 om 01:46:40 UTC |
| 1700000000 | 14 november 2023 om 22:13:20 UTC |
| 2000000000 | 18 mei 2033 om 03:33:20 UTC |
| 2147483647 | 19 januari 2038 om 03:14:07 UTC |
Neem 1700000000 als voorbeeld. Eén miljard seconden na de epoch beland je op 9 september 2001, ongeveer 31,7 jaar later, want een jaar telt ruim 31,5 miljoen seconden. Nog eens 700 miljoen seconden erbij, ruim 22 jaar, brengt je bij 14 november 2023 om 22:13:20 UTC. Je hoeft die som nooit zelf uit te rekenen: dat is precies waar een converter voor is, maar het helpt om te zien dat elke stap gewoon “seconden optellen bij 1 januari 1970” is, en niets ingewikkelders.
Seconden of milliseconden? Het verschil herkennen
De klassieke valkuil bij Unix-timestamps is verwarring tussen seconden en milliseconden. Een timestamp in seconden heeft anno nu 10 cijfers, zoals 1700000000. Diezelfde tijd in milliseconden heeft 13 cijfers: 1700000000000, hetzelfde moment, 14 november 2023, alleen duizend keer zo fijnmazig uitgedrukt.
JavaScript’s Date.now() en veel web-API’s geven standaard milliseconden terug, terwijl Unix-systeemaanroepen, cron en de meeste Linux-tooling seconden verwachten. Plak je per ongeluk een millisecondenwaarde in een veld dat seconden verwacht, dan vermenigvuldig je de tijd effectief met duizend en beland je duizenden jaren in de toekomst, ver voorbij elke zinnige datum. Klopt de datum die een tool teruggeeft ineens niet meer en zit je ergens diep in de volgende eeuw, tel dan eerst de cijfers van je timestamp: 10 cijfers is seconden, 13 is milliseconden.
Een timestamp omzetten naar een datum
Sta je voor een created_at-waarde in een database-export of een timestamp in een logregel en wil je weten welk moment dat precies was? Vul de waarde hieronder in en de tool zet hem meteen om naar een leesbare datum en tijd.
Een datum omzetten naar een timestamp
Andersom kom je dit net zo vaak tegen. Je plant bijvoorbeeld een cron-job voor een specifiek moment, of je moet het exp-veld van een JWT-token instellen op een datum en tijd over een uur, en de API waarmee je werkt verwacht daarvoor een Unix-timestamp. Kies hieronder een datum en tijd en zie meteen welk getal daarbij hoort.
Veelgemaakte fouten en edge cases
Seconden en milliseconden door elkaar halen. Zoals hierboven beschreven is dit verreweg de meest voorkomende fout: een JavaScript-timestamp met 13 cijfers in een veld plakken dat seconden verwacht, of andersom, geeft een datum die duizend keer te vroeg of te laat is.
Het Jaar 2038-probleem. Systemen die een Unix-timestamp opslaan als 32-bits ondertekend geheel getal lopen vast op 2147483647, oftewel 19 januari 2038 om 03:14:07 UTC. Eén seconde later slaat het getal om naar een negatieve waarde en breekt de datumlogica van dat systeem. Moderne 64-bits systemen kennen deze limiet niet, maar oudere embedded software en sommige databaseformaten wel.
Verwarring rond tijdzones. Een Unix-timestamp zelf heeft geen tijdzone, het is simpelweg een absoluut moment in de tijd. De verwarring ontstaat pas bij het weergeven ervan: kies je UTC of lokale tijd? Iemand in Amsterdam en iemand in New York die naar dezelfde timestamp 1700000000 kijken, zien elk een andere klok, maar het is voor beiden precies hetzelfde moment.
Negatieve timestamps. Een negatieve waarde staat voor een moment vóór 1 januari 1970. Zo komt -86400 overeen met 31 december 1969, exact 86400 seconden (een dag) vóór de epoch. Niet elk systeem of elke tool ondersteunt negatieve timestamps, dus data van vóór 1970 kunnen daar problemen geven.
Een timestamp als string behandelen in plaats van als getal. In sommige API-responses of CSV-exports staat een Unix-timestamp tussen aanhalingstekens, bijvoorbeeld "1700000000". Rekenkundig blijft het dezelfde waarde, maar als je hem per ongeluk als tekst blijft vergelijken in plaats van als getal, sorteren waarden als “2000000000” en “999999999” verrassend genoeg alfabetisch in plaats van chronologisch, omdat “2” vóór “9” komt. Cast de waarde altijd expliciet naar een geheel getal voordat je ermee rekent of sorteert.
Veelgestelde vragen
Wat is een Unix-timestamp? Een Unix-timestamp is het aantal seconden dat verstreken is sinds 1 januari 1970, 00:00:00 UTC, ook wel de Unix-epoch genoemd. Het is een compacte, tijdzone-onafhankelijke manier om een exact moment in de tijd als één getal vast te leggen.
Hoe weet ik of mijn timestamp in seconden of milliseconden staat? Tel de cijfers. Een timestamp in seconden heeft momenteel 10 cijfers (zoals 1700000000), een timestamp in milliseconden heeft 13 cijfers voor hetzelfde moment (1700000000000). Kom je in een converter ineens uit op een datum ver in de toekomst, dan staat de waarde vrijwel zeker in milliseconden terwijl seconden werden verwacht.
Wat is het Jaar 2038-probleem? Systemen die een Unix-timestamp opslaan als 32-bits ondertekend geheel getal kunnen niet verder tellen dan 2147483647, wat overeenkomt met 19 januari 2038 om 03:14:07 UTC. Daarna slaat de waarde om naar een negatief getal, waardoor datumberekeningen fout gaan. Moderne 64-bits systemen hebben dit probleem niet.
Kan ik een datum van vóór 1970 omzetten? Ja, dat resulteert in een negatieve timestamp. Bijvoorbeeld, -86400 staat voor 31 december 1969. Houd er wel rekening mee dat niet elke tool of elk systeem negatieve waarden accepteert.
Waarom slaan databases datums op als Unix-timestamp in plaats van als tekst? Omdat een timestamp een geheel getal is: compact om op te slaan, snel om te sorteren en zonder tijdzone-gedoe te vergelijken. Twee timestamps vergelijken is simpele wiskunde, terwijl twee geformatteerde datumstrings vergelijken eerst parsen vereist en makkelijk misgaat door verschillen in notatie of tijdzone.