Zet een Unix-tijdstempel in seconden, milliseconden, microseconden of nanoseconden om naar een datum in UTC of een belangrijke wereldtijdzone, en een datum terug naar een tijdstempel.
Niets wat je invoert wordt opgeslagen - het wordt in hetzelfde verzoek omgezet en teruggestuurd.
Logs, databases en API's slaan tijd op als Unix-timestamp: het aantal seconden sinds 1 januari 1970 UTC. Plak er een om de echte datum en tijd in je tijdzone te zien, of zet een datum om in de timestamp die een query of API-aanroep nodig heeft.
Een timestamp voor een datum van nu heeft 10 cijfers in seconden (1767225600 is 1 januari 2026, 00:00 UTC), 13 in milliseconden, 16 in microseconden en 19 in nanoseconden. De tool kijkt naar de grootte: waarden onder 10^11 gelden als seconden, onder 10^14 als milliseconden, onder 10^17 als microseconden en alles daarboven als nanoseconden. Date.now() in JavaScript en de meeste Java-API's geven milliseconden; Unix-tools, time.time() in Python en de meeste databases geven seconden. Je kunt de eenheid ook zelf kiezen.
Een Unix-timestamp is altijd UTC; de tijdzone telt pas als je hem aan een mens laat zien. Andersom kan een lokale tijd dubbelzinnig zijn: als de klok terug gaat, komt 01:30 twee keer voor, en als hij vooruit gaat, bestaat 02:30 helemaal niet. De tool waarschuwt in beide gevallen in plaats van stilzwijgend te kiezen. Dat is de gebruikelijke oorzaak van een rapport dat twee keer per jaar een uur verschuift.
Een negatieve timestamp is een datum vóór 1970: -86400 is 31/12/1969 om 00:00 UTC. De tool accepteert elk moment van -62135596800 (01/01/0001 00:00:00 UTC) tot 253402300799 (31/12/9999 23:59:59 UTC). Decimalen blijven bewaard als fracties van een seconde, dus 1700000000.5 is 14/11/2023 om 22:13:20.5 UTC. De herkenning kijkt alleen naar de grootte, dus een waarde in milliseconden van vóór 03/03/1973 heeft hoogstens 11 cijfers en wordt als seconden gelezen: 86400000 toont 27/09/1972 in plaats van 02/01/1970. Kies voor zulke oude waarden de eenheid Milliseconden.
In Excel of Google Sheets maakt =A1/86400+DATE(1970,1,1) van seconden in cel A1 een UTC-datum (deel door 86400000 voor milliseconden); geef de cel een datum- en tijdnotatie. Een Nederlandstalige Excel verwacht DATUM en puntkomma's: =A1/86400+DATUM(1970;1;1). Tel voor lokale tijd de UTC-afwijking in uren gedeeld door 24 op, bijvoorbeeld +1/24 voor Amsterdam in de winter. =(A1-DATE(1970,1,1))*86400 rekent een datum terug naar seconden. In PostgreSQL geeft to_timestamp(1700000000) een timestamptz en gaat EXTRACT(EPOCH FROM kolom) terug; in MySQL gebruiken FROM_UNIXTIME(1700000000) en UNIX_TIMESTAMP(kolom) de tijdzone van de sessie. Plak dezelfde waarde hier om een formule te controleren: 1700000000 moet 14/11/2023 22:13:20 UTC opleveren.
De waarde was waarschijnlijk in seconden maar is als milliseconden gelezen, of hij was 0 of leeg in het bronsysteem. Een datum in januari 1970 betekent bijna altijd een ontbrekende waarde, geen echte gebeurtenis.
Nee. Unix-tijd negeert schrikkelseconden, dus elke dag duurt precies 86.400 seconden. Zo slaan computers, databases en API's tijd ook op.
Tel de cijfers. Vandaag heeft een timestamp in seconden 10 cijfers en een in milliseconden 13. De converter herkent dit voor je, en je kunt de eenheid ook zelf instellen.
Nee. Hij telt seconden vanaf een vast moment in UTC, dus dezelfde timestamp is overal hetzelfde moment. Alleen de weergave hangt af van de tijdzone.
Systemen die de timestamp als signed 32-bit getal opslaan, lopen op 19/01/2038 over. Deze converter rekent met getallen op volle grootte en verwerkt datums tot het jaar 9999.
In JavaScript geeft Math.floor(Date.now() / 1000) seconden; Date.now() alleen geeft milliseconden. In Python int(time.time()). In een Linux- of macOS-shell date +%s. In PostgreSQL EXTRACT(EPOCH FROM now()) (met decimalen) en in MySQL UNIX_TIMESTAMP(). De live klok op deze pagina toont dezelfde waarde in seconden, klaar om te kopiëren.
40 gangbare zones uit de IANA-tijdzonedatabase, elk genoemd naar een stad, van UTC en Asia/Kolkata (India) tot America/Los_Angeles en Pacific/Auckland. Elke zone past voor de omgerekende datum zijn eigen zomertijdregels toe. De zone van je browser is vooraf gekozen als die in de lijst staat; anders begint de pagina op UTC. Staat je stad er niet bij, kies dan een stad uit de lijst met vandaag dezelfde klok, bijvoorbeeld Europe/Amsterdam voor Brussel.
Gebruik beide kaarten. Kies Asia/Kolkata als tijdzone, vul 14/11/2023 en 10:00 in bij Datum naar tijdstempel en klik op Omzetten: je krijgt 1699936200. Plak dat bij Tijdstempel naar datum en zet de tijdzone op America/New_York. Tijdstempel naar datum toont nu 13/11/2023 23:30:00 met UTC-verschil -05:00, de avond ervoor in New York. Zomertijd wordt toegepast voor de datum die je invult, dus 10:00 in India op 14/07/2023 is 00:30 op 14/07/2023 in New York, bij -04:00. Bij het wisselen van zone wordt de datum bij Datum naar tijdstempel ook opnieuw gelezen als New Yorkse tijd, dus lees het antwoord af bij Tijdstempel naar datum.
Attributen zoals lastLogonTimestamp en pwdLastSet zijn Windows FILETIME-waarden: intervallen van 100 nanoseconden sinds 01/01/1601 UTC, geen Unix-tijd. Als je 133446720000000000 zo plakt, wordt het als nanoseconden gelezen en zie je 25/03/1974. Deel eerst door 10000000 en trek 11644473600 af: de uitkomst, 1700198400, is 17/11/2023 05:20:00 UTC. In Excel geeft =A1/864000000000-109205 dezelfde UTC-datum en -tijd; in PowerShell [DateTime]::FromFileTimeUtc(133446720000000000).
Vul de delen in bij Datum naar tijdstempel: 14/11/2023 als datum en 22:13:20 als tijd. Kies een tijdzone met hetzelfde verschil op die datum, Asia/Kolkata voor +05:30 of UTC voor een waarde die op Z eindigt, en klik op Omzetten: de uitkomst is 1699980200. Heeft geen enkele zone in de lijst dat verschil, trek het dan zelf af en vul de tijd in UTC in: 22:13:20+05:30 is 16:43:20 UTC. Tijdstempel naar datum toont ISO 8601 in UTC en in lokale tijd, klaar om te kopiëren.