Werken met Unix-tijdstempels: epoch-tijd eenvoudig gemaakt

Open een API-antwoord of een databaserij en je vindt een datum vaak opgeslagen als een gewoon getal zoals 1751760000. Dat is een Unix-tijdstempel, en zo houdt een enorme hoeveelheid software de tijd bij. Deze gids legt uit wat dat getal betekent, waarom computers tijd zo tellen, en de valkuilen — seconden vs. milliseconden, tijdzones en het jaar 2038-probleem.

Wat een Unix-tijdstempel is

Een Unix-tijdstempel is het aantal seconden dat is verstreken sinds een vast moment dat de epoch heet: 00:00:00 UTC op 1 januari 1970. Dus 0 is de epoch zelf, 60 is één minuut later, en 1751760000 is een moment in 2025. Het is gewoon een doorlopende telling van seconden.

Waarom seconden vanaf 1970 tellen?

Tijd als één geheel getal voorstellen is enorm handig voor computers. Twee momenten vergelijken wordt twee getallen vergelijken; het gat ertussen vinden is aftrekken; gebeurtenissen sorteren is gewoon gehele getallen sorteren — allemaal zonder kalenders, maanden, schrikkeljaren of tijdzones om over na te denken. Het startpunt 1970 is een historische keuze uit de begindagen van het Unix-besturingssysteem die simpelweg bleef.

De seconden-vs-milliseconden-valkuil

Dit is de fout die bijna iedereen minstens één keer maakt. Unix-tijdstempels zijn klassiek in seconden, maar veel systemen — JavaScript in het bijzonder — gebruiken milliseconden (duizendsten van een seconde). De twee verschillen met een factor 1000:

seconden:      1751760000
milliseconden: 1751760000000

Voer een secondenwaarde in iets dat milliseconden verwacht en je datum belandt in 1970; doe het omgekeerde en hij belandt tienduizenden jaren in de toekomst. De snelle check: een actuele tijdstempel in seconden heeft 10 cijfers; in milliseconden 13. Wanneer een omgezette datum er absurd uitziet, is dat bijna altijd de reden.

Tijdzones en UTC

Een belangrijke kracht van Unix-tijdstempels: het getal zelf is altijd in UTC. Het stelt één exact moment voor, hetzelfde voor iedereen op aarde. De tijdstempel 1751760000 is één moment; of die als 16.00 uur in Londen of 11.00 uur in New York wordt getoond, is puur een weergavekeuze die je op het eind toepast. Tijd als UTC-tijdstempel opslaan en pas bij het tonen naar lokale tijd omzetten, voorkomt een hele categorie tijdzonebugs. Om hetzelfde moment in verschillende regio's te zien, is een tijdzone-omzetter het juiste gereedschap.

Naar en van menselijke datums omzetten

Je moet voortdurend beide kanten op — een tijdstempel omzetten naar een leesbare datum om een log te debuggen, of een datum naar een tijdstempel om een API te bevragen. Onze Unix-tijdstempel-omzetter doet beide direct en toont het resultaat in je lokale tijd en in UTC. Om in plaats daarvan het gat tussen twee datums te meten, doet de datumverschil-calculator dat rechtstreeks.

Het jaar 2038-probleem

Oudere systemen slaan de tijdstempel op als een 32-bits geheel getal met teken, dat maar tot 2.147.483.647 kan tellen. Dat plafond wordt bereikt om 03:14:07 UTC op 19 januari 2038 — één seconde later loopt de teller over en slaat om naar een negatief getal, waardoor datums terug naar 1901 vliegen. Het is dezelfde soort bug als Y2K. De oplossing is al wijdverbreid: gebruik een 64-bits geheel getal, dat de grens zo'n 292 miljard jaar vooruit schuift. De meeste moderne software is prima, maar het is goed om te weten bij het aanraken van legacy-systemen.

Snelle referentie

• Een Unix-tijdstempel = seconden sinds 1 januari 1970 UTC.
• 10 cijfers = seconden; 13 cijfers = milliseconden.
• De waarde is altijd UTC — pas tijdzones alleen bij het tonen toe.
• 32-bits opslag breekt in 2038; 64-bits niet.