Skip to content

Unix timestamp omrekenen — online converter

Reken Unix timestamps direct om naar datums. Herkent automatisch seconden, milliseconden en microseconden. Live klok, bidirectioneel. Gratis en privé.

Geen tracking Draait in je browser Gratis
Alle verwerking vindt plaats in je browser. Er wordt geen data naar een server verstuurd.

Huidige Unix timestamp

0

Snelle referentie

Codevoorbeelden

Gecontroleerd op POSIX-naleving en precisie-nauwkeurigheid — Go Tools Engineering Team · Mar 22, 2026

Wat is een Unix timestamp (epoch time)?

Een Unix timestamp (ook wel epoch time of POSIX time genoemd) is het aantal seconden dat verstreken is sinds1 januari 1970 00:00:00 UTC — de universele tijdreferentie voor vrijwel alle computersystemen. Van Linux-kernels en SQL-databases tot JavaScript-engines en mobiele besturingssystemen: vrijwel elk modern platform slaat tijd op als een Unix timestamp en wisselt die uit.

Zoals IEEE Std 1003.1 (POSIX) het formeel definieert: "De Unix epoch (1 januari 1970 00:00:00 UTC) fungeert als nulpunt voor POSIX-tijd" — een conventie zo universeel aangenomen dat ze nu de facto standaard is voor machine-leesbare timestamps wereldwijd. Unix timestamps worden gebruikt door de overgrote meerderheid van server-side systemen, databases en netwerkprotocollen, inclusief HTTP-headers, JWT-tokens en vrijwel elke REST API.

De Unix epoch zelf — 1 januari 1970 — is niet willekeurig gekozen. Unix werd ontwikkeld bij Bell Labs eind jaren zestig, en 1970 was een handig, rond startpunt dat recent genoeg was om alle relevante datums te vertegenwoordigen met beheersbare integer-groottes. Elk moment in de tijd kan worden uitgedrukt als een getekend 64-bit geheel getal dat de seconden telt vanaf dat ankerpunt. Datums vóór de epoch worden weergegeven als negatieve getallen: 31 december 1969 om middernacht UTC is -86400 (één dag, ofwel 86.400 seconden, vóór de epoch).

Moderne systemen hebben vaak een fijnere tijdsresolutie nodig dan hele seconden. Daartoe worden timestamps doorgaans uitgedrukt in milliseconden (duizendsten van een seconde, zoals geretourneerd door JavaScript's `Date.now()` of Java's `System.currentTimeMillis()`) of microseconden (miljoensten van een seconde, gebruikt in databases zoals PostgreSQL en in high-frequency trading-systemen). Je herkent de precisie aan het aantal cijfers: 10 cijfers wijst op seconden, 13 cijfers op milliseconden en 16 cijfers op microseconden. Deze converter herkent de precisie van je input automatisch.

Unix timestamps vormen de ruggengraat van gedistribueerd computergebruik omdat ze tijdzone-onafhankelijk zijn, monotoon toenemen (onder normale omstandigheden) en gemakkelijk als integers te sorteren zijn. Tijden opslaan als timestamps en ze alleen bij weergave omzetten naar mensvriendelijke formaten is een aanbevolen aanpak die hele categorieën tijdzone-bugs elimineert. De keerzijde is leesbaarheid — een ruwe timestamp zoals 1741965432 is ondoorzichtig zonder een converter, en dat is precies wat deze tool biedt.

Alle omrekeningen vinden volledig in je browser plaats via de JavaScript Date API — er worden geen timestamps, datums of andere data naar een server verstuurd. Deze tool rekent elke Unix timestamp — inclusief de huidige epoch-tijd in de live klok hierboven — direct om naar een mensvriendelijke datum, volledig privé.

Timestamps zijn nauw verwant aan andere developer-tools. UUID v1 en v7 bevatten timestamps direct in hun identifiers, en API-responses met timestamps zijn vaak het best te inspecteren met een JSON formatter voor betere leesbaarheid. JWT-tokens bevatten ook timestamp-claims (iat, exp) die je direct kunt plakken in de JWT decoder voor snelle verificatie.

// Get the current Unix timestamp in JavaScript
const timestampSeconds = Math.floor(Date.now() / 1000);
console.log(timestampSeconds); // → 1741965432

// Milliseconds (native JavaScript)
const timestampMs = Date.now();
console.log(timestampMs); // → 1741965432000

// Convert timestamp back to a Date object
const date = new Date(timestampSeconds * 1000);
console.log(date.toISOString()); // → '2025-03-14T15:37:12.000Z'

// Python equivalent
// import time
// timestamp = int(time.time())  # → 1741965432

Belangrijkste functies

Automatische precisieherkenning

Herkent automatisch of je timestamp in seconden (10 cijfers), milliseconden (13 cijfers) of microseconden (16 cijfers) staat — zonder handmatig omschakelen.

Bidirectionele omrekening

Reken timestamps om naar mensvriendelijke datums, of kies een datum en tijd om direct de bijbehorende Unix timestamp in alle drie precisieformaten te krijgen.

Live epoch-klok

Zie de huidige Unix timestamp in realtime tikken, zodat je altijd een nauwkeurig referentiepunt hebt voor je omrekeningen en berekeningen.

Uitvoer in meerdere formaten

Elke omrekening toont tegelijk UTC, je lokale tijdzone, ISO 8601 en een mensvriendelijke relatieve tijd (bijv. "3 dagen geleden").

100% verwerking in de browser

Alle omrekeningen vinden volledig in je browser plaats via de JavaScript Date API. Er worden geen timestamps, datums of persoonsgegevens naar een server verstuurd.

Unix timestamp versus andere datumformaten

ISO 8601

2025-03-14T15:37:12Z

Zowel mensvriendelijk als lexicografisch sorteerbaar. De standaard voor data-uitwisseling en API's. Verkieslijk boven Unix timestamps wanneer leesbaarheid voor mensen belangrijk is.

RFC 2822

Fri, 14 Mar 2025 15:37:12 +0000

Mensvriendelijk maar niet sorteerbaar. Wordt voornamelijk gebruikt in e-mailheaders (Date-veld). Minder compact dan ISO 8601 en Unix timestamps.

Mensvriendelijke datum

14 maart 2025 15:37

Het meest leesbare formaat voor eindgebruikers, maar niet sorteerbaar en niet geschikt voor programmatisch gebruik. Het beste gereserveerd voor de weergavelaag van de gebruikersinterface.

Omrekenvoorbeelden

Standaard Unix timestamp (seconden)

1741965432
2025-03-14T15:37:12Z

Een 10-cijferige timestamp in seconden — het meest gebruikte formaat door Unix/Linux-systemen, Unix API's, JWT-tokens en serverlogboeken. Deze waarde komt overeen met Pi Day 2025 om 15:37:12 UTC.

Y2K timestamp — 1 januari 2000

946684800
2000-01-01T00:00:00Z

De Unix timestamp voor het Y2K-moment: precies 946.684.800 seconden na de Unix epoch. Dit is een handige kalibreerwaarde — als je converter 1 januari 2000 retourneert voor deze input, werkt hij correct.

Negatieve timestamp (vóór de epoch)

-86400
1969-12-31T00:00:00Z

Negatieve Unix timestamps staan voor datums vóór 1 januari 1970. De waarde -86400 is precies één dag (86.400 seconden) vóór de epoch, wat neerkomt op 31 december 1969 om middernacht UTC. Niet alle systemen ondersteunen negatieve timestamps, maar deze converter verwerkt ze correct.

Millisecondentimestamp (13 cijfers)

1741965432000
2025-03-14T15:37:12.000Z

Een 13-cijferige timestamp in milliseconden — het native formaat van JavaScript's Date.now(), Java's System.currentTimeMillis() en de meeste moderne REST API's. Dit is gelijk aan het eerste voorbeeld vermenigvuldigd met 1000. De automatische herkenning ziet de 13-cijferige lengte en verwerkt het correct als milliseconden.

Zo gebruik je het

  1. 1

    Kies de omrekenrichting

    Kies "Timestamp → Date" om een Unix timestamp te decoderen naar een mensvriendelijke datum, of "Date → Timestamp" om een kalenderdatum en -tijd om te rekenen naar een Unix timestamp.

  2. 2

    Voer je waarde in

    Plak of typ een Unix timestamp (bijv. 1741965432 of 1741965432000) in het invoerveld. De tool herkent automatisch of het seconden, milliseconden of microseconden zijn. Voor Date → Timestamp selecteer je het jaar, de maand, dag, uur, minuut en seconde via de datumkiezer.

  3. 3

    Kopieer het omgezette resultaat

    Zie direct het resultaat in UTC, lokale tijd, ISO 8601 en relatieve tijd. Klik op de knop Kopiëren naast elk formaat om het direct naar je klembord te kopiëren.

Veelvoorkomende toepassingen

API-ontwikkeling en debugging
Decodeer ondoorzichtige timestamps in API-responses, JWT-tokenpayloads (iat-, exp- en nbf-claims), webhook-eventdata en logvermeldingen. Controleer direct of een authenticatietoken verlopen is of wanneer een event heeft plaatsgevonden.
Databasetimestampopslag en -queries
Reken om tussen Unix timestamps en mensvriendelijke datums bij het schrijven van databasequeries, het inspecteren van opgeslagen records of het valideren dat datumbereikfilters correct zijn opgegeven in je WHERE-clausules.
Logbestandanalyse en correlatie
Veel systeem- en applicatielogboeken registreren events als Unix timestamps. Reken verdachte logvermeldingen om naar mensvriendelijke tijden om events over meerdere services te correleren, aanvalsvensters te identificeren of het exacte moment van een fout te lokaliseren.
JWT-tokenvervaldatumverificatie
JSON Web Tokens encoderen iat (issued at), exp (expires at) en nbf (not before) als Unix timestamps in hun payload. Plak deze waarden direct om tokengeldigheidsvensters te verifiëren zonder de epoch-berekening handmatig te doen.
Cron-taakplanning
Verifieer dat cron-taakschema's, geplande taken en tijdgestuurde triggers overeenkomen met de bedoelde uitvoeringsvensters door voorgestelde uitvoertijden om te rekenen naar timestamps en terug.
Tijdzone-neutrale datumcoördinatie
Unix timestamps zijn van nature tijdzone-neutraal. Gebruik deze converter om een gedeeld referentiepunt vast te stellen bij het coördineren van datums en deadlines over teams in verschillende tijdzones, waarbij je het UTC-equivalent van een lokale tijd bevestigt.

Technische referentie

Definitie van een Unix timestamp
Een Unix timestamp is het gehele getal van seconden dat verstreken is sindsde Unix epoch: 1 januari 1970, 00:00:00 UTC (Coordinated Universal Time). De waarde is onafhankelijk van de lokale tijdzone van de waarnemer, waardoor het een ideale tijdzone-neutrale representatie is voor het opslaan en vergelijken van tijden.
Maximale waarde van een 32-bit signed integer
De maximale waarde van een getekend 32-bit integer is 2.147.483.647. Als Unix timestamp komt dit overeen met 19 januari 2038 om 03:14:07 UTC. Systemen die timestamps opslaan in 32-bit signed integers lopen op dit moment over — een probleem bekend als het Jaar 2038-probleem. 64-bit systemen kunnen datums miljarden jaren in de toekomst weergeven.
JavaScript gebruikt milliseconden
JavaScript's Date.now() en new Date().getTime() retourneren het aantal milliseconden sindsthe epoch — niet seconden. Dit levert 13-cijferige getallen op. Om om te rekenen naar de standaard Unix timestamp in seconden, deel je door 1000 en rond je naar beneden af: Math.floor(Date.now() / 1000). Veel API's en tools verwachten seconden, dus deze omrekeningsstap is cruciaal.
Negatieve timestamps staan voor datums vóór de epoch
Unix timestamps kunnen negatief zijn om datums vóór 1 januari 1970 te vertegenwoordigen. Zo staat -86400 voor 31 december 1969 om 00:00:00 UTC. Het bereik van een getekende 64-bit timestamp strekt zich uit van ongeveer 292 miljard jaar vóór de epoch tot 292 miljard jaar erna — ruim genoeg voor elke praktische toepassing.
Unix time houdt geen rekening met schrikkelseconden
Unix time gaat uit van precies 86.400 seconden per dag (24 uur × 60 minuten × 60 seconden). In werkelijkheid worden schrikkelseconden soms ingevoegd door IERS om UTC gesynchroniseerd te houden met de rotatie van de aarde. Daardoor is Unix time niet perfect lineair ten opzichte van TAI (International Atomic Time), en het verschil groeit in de loop van de tijd. Voor de meeste toepassingen is dit verschil niet relevant, maar precisie-tijdmeetsystemen moeten er rekening mee houden.

Aanbevolen aanpak

Sla timestamps altijd op in UTC
Sla timestamps op in UTC (of als Unix timestamps) en zet ze alleen bij weergave om naar lokale tijd. Tijdzones mengen in je database is een veelvoorkomende oorzaak van bugs die moeilijk te reproduceren en te debuggen zijn, met name rondom overgangen van zomertijd.
Gebruik millisecondenprecisie voor moderne API's
De meeste moderne API's, JavaScript-omgevingen en databases gebruiken milliseconden (13-cijferige timestamps) in plaats van seconden (10-cijferige timestamps). Controleer bij integratie met externe systemen altijd de verwachte precisie — een millisecondentimestamp doorgeven waar seconden verwacht worden levert datums op van ongeveer 11.000 jaar in de toekomst.
Houd rekening met het Jaar 2038-probleem
Systemen die Unix timestamps opslaan in 32-bit signed integers lopen over op 19 januari 2038 om 03:14:07 UTC. Controleer legacy systemen op 32-bit timestampvelden en migreer naar 64-bit integers of ISO 8601-strings. De meeste moderne talen en databases gebruiken standaard 64-bit timestamps, maar embedded systemen, oudere databases en bestandssystemen kunnen nog kwetsbaar zijn.
Vertrouw nooit op client-side klokken voor beveiliging
Klokken van client-apparaten kunnen op elke waarde worden ingesteld, per ongeluk of met kwade bedoelingen. Gebruik een door de client aangeleverde timestamp nooit voor beveiligingsgevoelige logica zoals JWT-vervaldatumcontroles, sessietime-outs of rate limiting. Valideer timestamps altijd op de server via een betrouwbare tijdbron.
Gebruik ISO 8601 voor mensvriendelijke uitwisseling
Als je een timestampformaat nodig hebt dat zowel machine-leesbaar als mensvriendelijk is — bijvoorbeeld in logbestanden, configuratiebestanden of API-responses waar een ontwikkelaar de output kan lezen — is ISO 8601 (bijv. 2025-03-14T15:37:12Z) de beste keuze. Het is lexicografisch sorteerbaar, ondubbelzinnig en wordt ondersteund door vrijwel alle moderne parsers.

Veelgestelde vragen

Waarom begint Unix time op 1 januari 1970?
De Unix epoch-datum van 1 januari 1970 werd gekozen door de ontwikkelaars van Unix bij Bell Labs eind jaren zestig als een handig, rond startpunt dat zowel recent als rekenkundig praktisch was. Destijds werden timestamps opgeslagen in 32-bit integers, dus de epoch moest dicht genoeg bij het heden liggen zodat gangbare datums in een redelijk kleine integer pasten. 1970 was simpelweg een schoon, rond jaar dat na het begin van de systeemontwikkeling viel. Er is geen diepe technische betekenis aan 1 januari 1970 specifiek — het was een pragmatische engineeringskeuze. Andere systemen kozen andere epochs: de klassieke Macintosh toolbox gebruikte 1 januari 1904; Windows NT gebruikt 1 januari 1601; GPS time begint op 6 januari 1980. Elk weerspiegelt het tijdperk en de ontwerpeisen van het systeem dat ervoor koos. Wat de Unix epoch deed standhouden is dat Unix het dominante besturingssysteem in de informatica werd, waarna elke grote programmeertaal, database en elk besturingssysteem Unix time adopteerde als universele standaard voor machine-leesbare timestamps. Vandaag de dag is de Unix epoch effectief een universele constante in de informatica, erkend door elk groot platform van Linux-kernels tot JavaScript-engines tot SQL-databases. De keuze heeft één bekende consequentie: datums vóór 1 januari 1970 worden weergegeven als negatieve getallen, die sommige oudere systemen niet aankunnen. Voor historische datums en astronomische berekeningen worden soms alternatieve timestampformaten gebruikt. Voor de overgrote meerderheid van softwareontwikkeling dekt de Unix epoch echter alle relevante datums ruimschoots.
Wat is het Jaar 2038-probleem?
Het Jaar 2038-probleem (ook wel Y2K38 of de Epochalypse genoemd) is een computerprobleem dat systemen treft die Unix timestamps opslaan als getekende 32-bit integers. Een getekende 32-bit integer kan waarden bevatten van -2.147.483.648 tot 2.147.483.647. Als Unix timestamp neerkomt de maximumwaarde van 2.147.483.647 op 19 januari 2038 om 03:14:07 UTC. Één seconde later loopt de teller over en springt terug naar de meest negatieve representeerbare waarde, die overeenkomt met 13 december 1901 — waardoor deze systemen toekomstige datums als ver in het verleden interpreteren. De gevolgen kunnen variëren van triviaal tot catastrofaal, afhankelijk van hoe timestamps worden gebruikt. Systemen kunnen geldige toekomstige datums afwijzen bij invoervalidatie, tijdgevoelige records onjuist sorteren, vervaldatums van certificaten en tokens fout berekenen, of volledig crashen bij het tegenkomen van de overflowwaarde. De oplossing is eenvoudig: migreer naar 64-bit signed integers voor timestampopslag. Een 64-bit timestamp kan datums weergeven van ongeveer 292 miljard jaar voor en na de epoch — ruim voorbij elke praktische bezorgdheid. De meeste moderne besturingssystemen, programmeertalen en databases gebruiken intern al 64-bit timestamps. Het risico zit in legacy code, embedded systemen, 32-bit besturingssystemen die nog in productie zijn, metagegevens van bestandssystemen (zoals de timestampvelden van FAT32) en databasekolommen die als INT zijn gedefinieerd in plaats van BIGINT. Ontwikkelaars moeten hun systemen nu al controleren. De migratie van 32-bit naar 64-bit timestamps moet vóór 2038 plaatsvinden, en in de praktijk kunnen systemen met langlopende records (hypotheken, infrastructuuractiva, juridische documenten) het probleem al veel eerder tegenkomen als toekomstige datums in getroffen velden worden ingevoerd.
Wat is het verschil tussen seconden-, milliseconden- en microsecondetimestamps?
Unix timestamps komen in drie gangbare precisieniveaus, te onderscheiden aan het aantal cijfers in de waarde: **Seconden (10 cijfers)**: Het originele en meest gebruikte Unix-timestampformaat. `1741965432` staat voor een specifieke seconde. Gebruikt door: Unix/Linux-systeemaanroepen (`time()`), de meeste Unix-hulpprogramma's, JWT-tokens (`iat`- en `exp`-claims), HTTP-headers (`Last-Modified`) en veel REST API's. De huidige timestamp is ongeveer 10 cijfers lang. **Milliseconden (13 cijfers)**: Een duizendste van een seconde precisie. `1741965432000` is hetzelfde moment als hierboven, vermenigvuldigd met 1.000. Gebruikt door: JavaScript's `Date.now()`, Java's `System.currentTimeMillis()`, Node.js, de meeste moderne JavaScript/TypeScript API's, Redis en veel database-clients. Als je een 13-cijferige timestamp in een JSON API-response ziet, zijn het vrijwel zeker milliseconden. **Microseconden (16 cijfers)**: Een miljoenste van een seconde precisie. `1741965432000000` is hetzelfde moment vermenigvuldigd met 1.000.000. Gebruikt door: PostgreSQL's `TIMESTAMP`- en `TIMESTAMPTZ`-typen, Python's `time.time_ns()` (dat overigens nanoseconden retourneert), high-frequency trading-systemen en tools voor netwerkpakketanalyse. De meest gemaakte fout is precisieniveaus door elkaar halen — bijvoorbeeld een millisecondentimestamp doorgeven aan een functie die seconden verwacht. Dit levert datums op van ongeveer 11.574 jaar in de toekomst. Controleer altijd de documentatie van de API of het systeem waarmee je werkt om de verwachte precisie te bevestigen, en gebruik de automatische herkenning van deze converter als sanity check.
Houdt Unix time rekening met schrikkelseconden?
Nee — Unix time houdt geen rekening met schrikkelseconden, en dit is een bekende beperking voor toepassingen die precisie-tijdmeting vereisen. Schrikkelseconden worden soms ingevoegd (of theoretisch verwijderd, hoewel dat nog nooit is gebeurd) door de International Earth Rotation and Reference Systems Service (IERS) om UTC gesynchroniseerd te houden met de iets onregelmatige rotatie van de aarde. Vanaf 2026 zijn er 27 schrikkelseconden ingevoegd sindsze voor het eerst werden geïntroduceerd in 1972. Unix time gaat uit van een perfect regelmatige kalender met precies 86.400 seconden per dag (24 × 60 × 60). Wanneer een schrikkelseconde wordt ingevoegd, heeft de echte wereld een seconde die Unix time negeert. Verschillende besturingssystemen gaan hier anders mee om: Linux smeert de schrikkelseconde traditioneel door de klok enige tijd rondom het invoegmoment iets langzamer te laten lopen (de aanpak van Google, ook wel "leap smearing" genoemd); sommige systemen dupliceren de seconde op 23:59:60 UTC; andere slaan de aanpassing simpelweg over. Voor de overgrote meerderheid van softwaretoepassingen — webservices, API's, databases, bedrijfslogica — is het verschil van ~27 gecumuleerde schrikkelseconden over meer dan 50 jaar volledig irrelevant. Het verschil is niet merkbaar voor mensgerichte toepassingen. Waar schrikkelseconden wél belangrijk zijn: GPS-synchronisatie, astronomische waarnemingen, precisie-tijdprotocollen voor pakketnetwerken (PTP/IEEE 1588) en elk systeem dat Unix timestamps nauwkeurig moet correleren met TAI (International Atomic Time). Als je toepassing in deze categorieën valt, gebruik dan een tijdbibliotheek die expliciet schrikkelsecondenbewustzijn ondersteunt, of werk direct met TAI-timestamps.
Kunnen Unix timestamps negatief zijn?
Ja, Unix timestamps kunnen negatief zijn, en negatieve timestamps zijn een legitieme en goed gedefinieerde manier om datums vóór de Unix epoch (1 januari 1970, 00:00:00 UTC) te vertegenwoordigen. Elke seconde vóór de epoch komt neer op een verlaging van 1 ten opzichte van nul. Zo staat -1 voor 31 december 1969 om 23:59:59 UTC; -86400 staat voor 31 december 1969 om 00:00:00 UTC (precies één dag vóór de epoch); en -2208988800 staat voor 1 januari 1900 om 00:00:00 UTC. De meeste moderne programmeertalen en besturingssystemen ondersteunen negatieve timestamps. Python's `datetime.fromtimestamp(-86400)` retourneert correct 31 december 1969. JavaScript's `new Date(-86400 * 1000)` geeft dezelfde datum correct weer. PostgreSQL slaat timestamps op als 8-byte integers en verwerkt datums duizenden jaren vóór de epoch correct. Er zijn echter belangrijke kanttekeningen. Sommige oudere systemen, bibliotheken of databasedrivers ondersteunen negatieve timestamps mogelijk niet correct. 32-bit systemen die unsigned integers gebruiken voor timestamps kunnen helemaal geen negatieve waarden weergeven. Sommige databases die zijn gedefinieerd als UNSIGNED BIGINT of DATETIME-typen kunnen negatieve waarden afwijzen of ze interpreteren als datums ver in de toekomst. Voor historische datums (alles vóór 1970) is het vaak veiliger om de datum op te slaan als een ISO 8601-string of een native datumtype van de database te gebruiken in plaats van te vertrouwen op negatieve Unix timestamps voor portabiliteit. Deze converter verwerkt negatieve timestamps correct en toont de bijbehorende pre-1970-datum.
Zo haal je de huidige Unix timestamp op in JavaScript, Python of andere talen
De huidige Unix timestamp ophalen is eenvoudig in elke gangbare programmeertaal: **JavaScript / TypeScript:** ```javascript // Seconds (most APIs expect this) const seconds = Math.floor(Date.now() / 1000); // Milliseconds (JavaScript native) const milliseconds = Date.now(); ``` **Python:** ```python import time seconds = int(time.time()) # 1741965432 import datetime milliseconds = int(datetime.datetime.now(datetime.UTC).timestamp() * 1000) ``` **Go:** ```go import "time" seconds := time.Now().Unix() // int64 milliseconds := time.Now().UnixMilli() // int64 microseconds := time.Now().UnixMicro() // int64 ``` **Java:** ```java long seconds = System.currentTimeMillis() / 1000L; long milliseconds = System.currentTimeMillis(); // Or with java.time (Java 8+): long seconds2 = Instant.now().getEpochSecond(); ``` **PHP:** ```php $seconds = time(); // integer $milliseconds = round(microtime(true) * 1000); ``` **Ruby:** ```ruby seconds = Time.now.to_i milliseconds = (Time.now.to_f * 1000).to_i ``` **Bash / Shell:** ```bash date +%s # seconds date +%s%3N # milliseconds (GNU date) ``` Het belangrijkste om te onthouden is dat JavaScript van nature in milliseconden werkt, terwijl vrijwel elke andere taal standaard seconden gebruikt. Wees altijd expliciet over welke precisie je gebruikt en leg dit vast in je API-contracten om integratiebugs te voorkomen.
Zo reken je epoch time om naar een mensvriendelijke datum
Er zijn drie snelle manieren om epoch time (Unix timestamps) om te rekenen naar een mensvriendelijke datum: **1. Gebruik deze online converter (snelst)** Plak je epoch timestamp in het invoerveld hierboven. De tool herkent automatisch of het seconden, milliseconden of microseconden zijn en toont direct het resultaat in UTC, je lokale tijdzone, ISO 8601 en relatieve tijd. Klik op Kopiëren om elk formaat te pakken. **2. Gebruik code** In JavaScript: `new Date(1741965432 * 1000).toISOString()` retourneert `'2025-03-14T15:37:12.000Z'`. In Python: `from datetime import datetime, UTC; datetime.fromtimestamp(1741965432, UTC)` geeft hetzelfde resultaat. Let op: JavaScript verwacht milliseconden, Python verwacht seconden — de meest voorkomende bron van omrekenbugs. **3. Gebruik de commandoregel** Op Linux of macOS met GNU date: `date -d @1741965432` (Linux) of `date -r 1741965432` (macOS). Op Windows PowerShell: `[DateTimeOffset]::FromUnixTimeSeconds(1741965432).DateTime`. Alle drie methoden geven hetzelfde resultaat. De online converter hierboven is de snelste optie als je snel een antwoord nodig hebt zonder een terminal te openen of code te schrijven.
Wat is de huidige Unix timestamp op dit moment?
De huidige Unix timestamp wordt weergegeven in de live klok bovenaan deze pagina, die elke seconde bijwerkt. De Unix timestamp is simpelweg het aantal seconden sinds1 januari 1970 00:00:00 UTC, en neemt elke seconde met precies 1 toe. Zo haal je de huidige timestamp programmatisch op: - **JavaScript**: `Math.floor(Date.now() / 1000)` (seconden) of `Date.now()` (milliseconden) - **Python**: `import time; int(time.time())` - **Bash**: `date +%s` Vanaf 2026 bevindt de huidige Unix timestamp zich in het bereik van 1,77 miljard (10 cijfers). Hij bereikt 2 miljard rond mei 2033, en de maximumwaarde voor 32-bit systemen (2.147.483.647) wordt bereikt op 19 januari 2038 om 03:14:07 UTC — het zogenoemde Jaar 2038-probleem. Sla deze pagina op als bladwijzer om altijd de huidige epoch-tijd binnen handbereik te hebben.
Ik moet een timestamp in mijn API-response debuggen — hoe reken ik die om?
Kopieer de timestampwaarde uit je API-response (het is doorgaans een 10- of 13-cijferig getal in een JSON-veld zoals "created_at" of "timestamp"). Plak het direct in het invoerveld hierboven — de tool herkent automatisch of het seconden of milliseconden zijn en toont direct de UTC-datum, je lokale tijd en ISO 8601. Als de timestamp in een JWT-token zit, decodeer dan eerst de JWT-payload (die Base64URL-geëncodeerd is) om de velden iat, exp of nbf te extraheren, en plak die waarden vervolgens hier. Je kunt ook de JWT decoder gebruiken om het volledige token in één stap te inspecteren. Voor het debuggen van meerdere timestamps tegelijk gebruik je het codefragment `new Date(timestamp * 1000).toISOString()` in je browserconsole om snel meerdere timestamps te controleren.
Zo haal je de huidige Unix timestamp op in Python, JavaScript of Go
In JavaScript gebruik je `Math.floor(Date.now() / 1000)` voor seconden of `Date.now()` voor milliseconden. In Python gebruik je `import time; int(time.time())` voor seconden, of `int(time.time() * 1000)` voor milliseconden. In Go gebruik je `time.Now().Unix()` voor seconden, `time.Now().UnixMilli()` voor milliseconden, of `time.Now().UnixMicro()` voor microseconden. Onthoud dat JavaScript van nature in milliseconden werkt, terwijl Python en Go standaard seconden gebruiken — dit is de meest voorkomende oorzaak van timestamp-bugs bij integratie van systemen in verschillende talen. Leg altijd vast welke precisie je API verwacht in je OpenAPI/Swagger-specificatie.
Wat gebeurt er met Unix timestamps bij overgangen van zomertijd?
Unix timestamps worden volledig niet beïnvloed door overgangen van zomertijd (DST) omdat ze gebaseerd zijn op UTC, dat geen zomertijd kent. Als klokken "vooruitgaan" of "terugvallen" in een lokale tijdzone, blijft de Unix timestamp gewoon met precies 1 per seconde toenemen, zonder gaten of herhalingen. Dit is één van de belangrijkste voordelen van tijden opslaan als Unix timestamps in plaats van lokale datum-tijdstrings. Als je echter een Unix timestamp omrekent naar een lokale tijd tijdens een DST-overgang, kan dezelfde lokale tijd overeenkomen met twee verschillende Unix timestamps (tijdens het "terugval"-uur wanneer klokken herhalen). Sla tijden altijd op in UTC en reken ze alleen bij weergave om naar lokale tijd.
Ik heb een timestamp in milliseconden — hoe reken ik die om naar seconden?
Deel de millisecondentimestamp door 1000 en laat de decimale waarde vallen. In JavaScript: `Math.floor(ms / 1000)`. In Python: `ms // 1000` (integer-deling). Zo wordt 1741965432000 (milliseconden) 1741965432 (seconden). Je herkent millisecondentimestamps aan hun 13-cijferige lengte, vergeleken met de 10-cijferige lengte van secondentimestamps. Deze tool herkent de precisie automatisch, dus je kunt beide formaten direct plakken. De omgekeerde omrekening (seconden naar milliseconden) is eenvoudigweg vermenigvuldigen met 1000: 1741965432 × 1000 = 1741965432000. Let op dat je een millisecondentimestamp niet per ongeluk doorgeeft aan een functie die seconden verwacht — het resultaat zou een datum zijn van ongeveer 11.574 jaar in de toekomst.

Gerelateerde tools

Alle tools bekijken →