Unix-tijdstempels zonder hoofdpijn
Vraag drie ontwikkelaars hoe laat het is en je krijgt misschien drie antwoorden, afhankelijk van waar ze zitten. Vraag het een Unix-tijdstempel en je krijgt precies één getal, hetzelfde voor iedereen op de planeet. Dat ene geheel getal is de reden waarom epuchtijd stilletjes ten grondslag ligt aan bijna elk logbestand, elke databaserij en elke API-respons die je ooit zult tegenkomen. Deze pagina legt uit wat dat getal betekent, hoe je het in beide richtingen kunt lezen, en waar het mensen in de val lokt.
Wat Unix-tijd feitelijk is
Een Unix-tijdstempel is het aantal seconden dat is verstreken sinds 00:00:00 UTC op 1 januari 1970, zonder schrikkelseconden mee te tellen. Dat moment heet de epoch, en het werd gekozen door vroege Unix-ingenieurs simpelweg omdat het een handige ronde datum was om van te tellen. Bij de epoch is de waarde precies 0. Elke seconde daarna voegt er een toe, dus het getal groeit alleen maar. Data vóór 1970 zijn ook volkomen geldig, uitgedrukt als negatieve gehele getallen.
Je ziet dit concept ook POSIX-tijd of, losjes, epochtijd noemen. Wat het label ook is, de werking is hetzelfde: één voortdurend stijgende teller van seconden. Omdat het een gewoon geheel getal is in plaats van een opgemaakte string, kan een computer het opslaan in een paar bytes en twee waarden vergelijken met een enkele aftreksom.
Seconden, milliseconden en varianten
Klassieke Unix-tijd telt hele seconden, wat het bekende tiencijferige getal geeft dat je tegenwoordig ziet. Maar veel omgevingen hebben een fijnere resolutie nodig. JavaScript werkt bijvoorbeeld in milliseconden en produceert een dertien-cijferig getal, en sommige systemen gaan verder naar microseconden of nanoseconden. Een betrouwbare vuistregel: een tiencijferig getal zijn seconden, dertien cijfers zijn milliseconden. Als je geconverteerde datum ergens rond 1970 belandt terwijl je de huidige dag verwachtte, heb je vrijwel zeker milliseconden in een secondenveld ingevoerd, of andersom. Onze converter detecteert de grootteorde automatisch zodat je zelden hoeft te gokken.
Waarom ontwikkelaars erop vertrouwen
Het grote voordeel is dat een tijdstempel tijdzoneonafhankelijk is. Het getal 1735689600 verwijst naar hetzelfde moment in Tokio, Berlijn en São Paulo. Dat getal opslaan in plaats van een opgemaakte lokale string betekent dat je nooit hoeft te vragen welke klok een waarde had. Sorteren is ook triviaal, omdat chronologische volgorde gewoon numerieke volgorde is, zodat een databaseindex op een tijdstempelkolom gebeurtenissen correct sorteert zonder te parsen. Rekenen is evenzeer eenvoudig: het verschil tussen twee gebeurtenissen is één aftreksom, en een dag toevoegen is 86400 optellen. Deze eigenschappen zijn precies de reden waarom logboeken, tokens, caches en berichtenwachtrijen allemaal grijpen naar epochtijd.
Conversie in beide richtingen
Van een tijdstempel naar een voor mensen leesbare datum gaan betekent het aantal seconden nemen en dat projecteren op een kalender, en dat dan opmaken in welke tijdzone je ook maar wilt. De andere kant op neem je een jaar, maand, dag en tijd, bepaal je in welke tijdzone die is uitgedrukt, en zet je dat terug naar seconden sinds de epoch. Ons tool doet beide richtingen direct in je browser, zodat niets wat je plakt je machine verlaat. Plak een getal om het te decoderen, of kies een datum om die te coderen, en lees het resultaat tegelijkertijd in zowel UTC als je lokale tijd.
UTC versus lokale tijd, de klassieke valkuil
Het tijdstempel zelf heeft geen tijdzone; het is altijd verankerd aan UTC. De verwarring ontstaat alleen wanneer je het weergeeft. Als je 1700000000 converteert en je scherm een avonduur toont terwijl een collega in een ander land een middagtijd ziet, is er niets kapot — jullie kijken allebei naar hetzelfde moment weergegeven op verschillende lokale klokken. Bugs sluipen naar binnen wanneer code een lokale datum leest alsof het UTC is, of een wandkloktijd vastlegt zonder de offset te registreren. De veilige gewoonte is UTC opslaan en verzenden, en alleen een lokale offset toepassen op het allerlaatste moment, wanneer je de waarde aan een persoon toont. Twijfel je, vergelijk dan met de UTC-regel in de converter in plaats van je lokale regel.
Het jaar 2038-probleem
Veel oudere systemen sloegen Unix-tijd op in een getekend 32-bits geheel getal. Dat veld heeft geen ruimte meer één seconde na 03:14:07 UTC op 19 januari 2038, wanneer de teller overloopt en terugwikkelt naar een negatief getal, waardoor datums mogelijk terugspringen naar 1901. Het is dezelfde soort probleem als het millenniumprobleem. Het goede nieuws is dat moderne besturingssystemen en programmeertalen grotendeels zijn overgestapt op 64-bits tijdstempels, die pas over ruwweg 292 miljard jaar zullen overlopen, dus voor nieuwe code is het grotendeels een historische curiositeit die het waard is te kennen, geen noodsituatie.
Zie voor meer browsergebaseerde hulpmiddelen onze ontwikkelaarstools, en als je de getallen zelf wilt bewerken, zijn de rekenmachines een klik verderop.
Veelgestelde vragen
Wat is een Unix-tijdstempel?
Het is het aantal seconden sinds 00:00:00 UTC op 1 januari 1970, zonder schrikkelseconden mee te tellen. Dat startmoment heet de epoch, en de teller neemt alleen maar toe in de loop van de tijd.
Waarom converteert mijn getal naar een datum rond 1970?
Je hebt waarschijnlijk seconden en milliseconden door elkaar gehaald. Een tiencijferig getal zijn seconden en een dertien-cijferig getal zijn milliseconden. Milliseconden in een secondenveld stoppen deelt de schijnbare tijd door ongeveer duizend, waardoor je dicht bij de epoch belandt.
Heeft een Unix-tijdstempel een tijdzone?
Nee. De waarde is altijd verankerd aan UTC. Een tijdzone komt pas in beeld wanneer je het tijdstempel weergeeft als een voor mensen leesbare datum, en dat is waarom hetzelfde getal voor verschillende mensen andere wandkloktijden kan tonen.
Hoe converteer ik een datum terug naar een tijdstempel?
Geef het jaar, de maand, de dag en de tijd op, bepaal in welke tijdzone die datum is uitgedrukt, en het tool zet dat terug naar seconden sinds de epoch. Je kunt beide richtingen direct in je browser op deze pagina doen.
Wat is het jaar 2038-probleem?
Systemen die Unix-tijd opslaan in een getekend 32-bits geheel getal lopen over één seconde na 03:14:07 UTC op 19 januari 2038. Moderne 64-bits tijdstempels vermijden dit voor miljarden jaren, dus de meeste huidige software is niet getroffen.
Worden mijn gegevens naar een server gestuurd?
Nee. De conversie draait volledig in je browser, zodat elk tijdstempel of elke datum die je plakt op je eigen apparaat blijft.