Unix-tijdstempel
Vul een tijdstempel in, dan verschijnt het ogenblik, of vul een datum in, dan verschijnt het getal.
Tijdstempel op dit moment
–
Seconden, milliseconden of microseconden. Negatieve getallen voeren terug tot vóór 1970.
- UTCdonderdag 4 september 2025 om 15.33.20
- Jouw tijd–
- ISO 86012025-09-04T15:33:20Z
- In seconden1757000000
- In milliseconden1757000000000
Schrijf als 2026-09-12 of 2026-09-12T14:30. Zonder zone wordt het als UTC gelezen.
Merkpunten
| Getal | Ogenblik |
|---|---|
| Het begin van het tijdperk1970-01-01T00:00:00Z | |
| Eén miljard seconden2001-09-09T01:46:40Z | |
| Waar tweeëndertig bits ophouden2038-01-19T03:14:07Z | |
| Twee miljard seconden2033-05-18T03:33:20Z |
Unixtijd telt geen schrikkelseconden. Een unixdag heeft altijd precies 86.400 seconden.
Zo werkt het
Unixtijd is het aantal seconden sinds 1 januari 1970 in UTC. Dat nulpunt is gekozen omdat het handig dichtbij lag toen de maat werd ingevoerd, niet omdat het op zichzelf iets betekent.
De maat telt geen schrikkelseconden. Een unixdag heeft altijd precies 86.400 seconden, ook op de dagen waarop UTC er een seconde bij kreeg. Dat houdt het rekenen eenvoudig, en unixtijd volgt toch de datum en kloktijd van UTC. Maar het verschil tussen twee tijdstempels is niet altijd de tijd die werkelijk verstreken is. Sinds 1972 zijn er 27 schrikkelseconden ingevoegd die unixtijd niet meetelt. Behalve voor satellietnavigatie maakt dat niets uit.
De eenheid wordt uit de grootte van het getal geraden. Alles onder de tien miljard wordt als seconden gelezen, wat tot het jaar 2286 reikt, grotere getallen als milliseconden of microseconden. De grens ligt daar zodat een jaartal uit het heden goed wordt gelezen.
Negatieve getallen voeren terug tot vóór 1970 en werken net zo.
Een 32-bits teller met teken loopt af op 19 januari 2038 om 03:14:07 UTC en springt daarna terug naar 1901. Dat is het jaar-2038-probleem, dezelfde soort fout als het millenniumprobleem, alleen binair. Systemen die met 64 bits tellen hebben er geen last van.
Een datum zonder zone in de tekst wordt als UTC gelezen, zodat dezelfde tekst overal hetzelfde getal geeft.
Zo wordt het getal gelezen
Spaties en liggende streepjes in het getal worden verwijderd voordat het wordt gelezen. Zonder gekozen eenheid beslist de grootte: onder de tien miljard wordt het getal als seconden gelezen, vanaf tien miljard als milliseconden en vanaf honderd biljoen als microseconden. Door die grenzen wordt een waarde in milliseconden van vóór 26 april 1970, en een waarde in microseconden van vóór 3 maart 1973, in de verkeerde eenheid gelezen. Nanoseconden zijn geen eenheid: 1.757.000.000.000.000.000 nanoseconden, dat is 4 september 2025, wordt als microseconden gelezen en komt uit in het jaar 57647. Haal in dat geval de laatste drie cijfers weg. Volgens de ECMAScript-standaard loopt de kalender van de browser 100 miljoen dagen naar beide kanten van 1970, tot 13 september 275760, en getallen daarbuiten geven een foutmelding.
Rekenvoorbeeld: waar 32 bits ophouden
2³¹ − 1 = 2.147.483.647 is het grootste getal dat een 32-bits teller met teken kan bevatten. Een seconde later staat zo’n teller op −2.147.483.648, wat de tool toont als 13 december 1901 om 20.45.52 uur UTC. Ogenblikken buiten die twee grenzen krijgen een waarschuwing: 2.147.483.648 geeft hem wel, 2.147.483.647 niet.
Datums als tekst
In JavaScript wordt 2026-09-12T14:30 volgens de ECMAScript-standaard als lokale tijd gelezen, maar 2026-09-12 als UTC. De tool leest beide als UTC, dus 2026-09-12T14:30 geeft altijd 1.789.223.400. Delen van een seconde worden naar beneden afgerond op de hele seconde.
Datums die niet bestaan, worden geweigerd: 2026-02-30 geeft een foutmelding, terwijl Date in V8, de engine van Chrome en Edge, er zonder waarschuwing 2 maart van maakt. 24:00 wordt aangenomen als het eind van de dag, zoals ECMAScript toestaat.
Schrikkelseconden en de tijd vóór 1970
POSIX definieert de seconden sinds de Epoch met een formule en zegt uitdrukkelijk dat de verhouding tot de werkelijke UTC niet is vastgelegd. ECMAScript zegt dat er geen tijdwaarde bestaat voor een ogenblik binnen een schrikkelseconde. Daarom geeft 2016-12-31T23:59:60Z, de laatste schrikkelseconde tot nu toe, de foutmelding dat het tijdstip niet bestaat, terwijl de seconde ervoor 1.483.228.799 geeft en middernacht daarna 1.483.228.800. Volgens de IERS was het verschil tussen de atoomtijd TAI en UTC 10 seconden in 1972, en het is 37 seconden sinds 1 januari 2017. IERS Bulletin C 72 meldt dat er eind december 2026 geen schrikkelseconde wordt ingevoegd.
Voor negatieve waarden laat POSIX de verhouding onbepaald. De tool volgt ECMAScript, dat met de gregoriaanse kalender terugrekent, ook vóór de invoering daarvan.