Encoders & Utilities

Unix Timestamp & Date Calculator

Converteer Unix-epochs naar leesbare data, bereken datumrekenen en verschillen tussen data.

UTC

Local

Unix

Unix timestamp Unit Timezone

Human date ISO 8601, RFC 2822, SQL DATETIME, or any parseable date string.

Mode

Over deze tool

Unix Timestamp & Date Calculator converteert tussen integer Unix-epochs en ISO 8601 / locale-geformatteerde datums in beide richtingen. Plak een getal en het vertelt u of u het seconden (10 cijfers), milliseconden (13 cijfers), microseconden (16) of nanoseconden (19) voerde — en rendert de overeenkomende datum in UTC, uw lokale tijdzone en elke tijdzone die u kiest uit de IANA-lijst. De andere kant op, plak een datumstring in elk gangbaar formaat en krijg de epoch.

Een tweede modus handelt datum-rekenkunde af: voeg dagen, uren, minuten toe aan of trek af van een basisdatum; bereken het verschil tussen twee datums als dagen/uren/minuten/seconden (of "3 jaar, 2 maanden, 14 dagen" als u kalendereenheden verkiest). Alle wiskunde draait in de browser via Temporal waar beschikbaar en anders een fallback-bibliotheek — geen tijdzone-verrassingen door DST-overgangen, schrikkelseconden (genegeerd, net als in Unix-tijd zelf) of de 2038-rollover (we verwerken 64-bit timestamps natively).

Wanneer gebruikt u deze tool

Logs debuggen. Een log-entry met epoch 1747459200 — plak het, zie "17 mei 2026 04:00 UTC", klaar.
Database-datum sanity checks. Verifieer dat een waarde opgeslagen als BIGINT ms werkelijk decodeert naar de verwachte menselijke datum.
SLA / cron-rekenkunde. "Wat is 72 uur vanaf nu in Amsterdam-tijd (Europe/Amsterdam)?" — beantwoord in twee klikken.
Token-vervaldatum. Een JWT's exp-claim is een epoch — plak hem hier voor het mensvriendelijke antwoord.

Over het 2038-probleem

32-bit signed Unix-timestamps overflowen op 03:14:07 UTC op 19 januari 2038 (de "Y2038"-bug). De fix is 64-bit timestamps gebruiken, wat de meeste moderne talen en databases vandaag standaard doen. Onze calculator gebruikt 64-bit intern — waarden voorbij 2038, en ruim voorbij het jaar 100.000, worden correct berekend. Legacy-systemen op embedded hardware zijn het resterende blootstellingsoppervlak.

Veelgestelde vragen

Waarom is mijn "timestamp" 13 cijfers lang?

Het is in milliseconden, niet seconden. JavaScript, Java en veel nieuwere API's defaulten naar milliseconde-resolutie; klassieke Unix is seconden. 10 cijfers = seconden (huidige tijdperk tot 2286), 13 cijfers = milliseconden, 16 cijfers = microseconden, 19 cijfers = nanoseconden. Onze parser detecteert de precisie aan het aantal cijfers en converteert dienovereenkomstig.

Verwerkt de tool tijdzones correct?

Ja — elke conversie toont UTC naast de tijdzone die u kiest (standaard de lokale zone van uw browser). Daylight-saving-overgangen worden gerespecteerd voor IANA-zones (bijv. "Europe/Amsterdam" verwerkt CET/CEST-shifts automatisch). Wees voorzichtig met vaste-offset-strings ("+02:00") — ze zien er hetzelfde uit op een normale dag maar negeren DST.

Waarom is mijn jaar-rekenkunde-antwoord anders dan een eenvoudige deling?

Omdat kalendereenheden ongelijkmatig zijn. Een "jaar" middelt 365,2425 dagen; sommige zijn 365, sommige zijn 366. Twee datums in "jaren en maanden" aftrekken vereist echte kalender-wandeling, niet alleen seconden delen. Onze tool doet de wandeling; een eenvoudige seconden / (365 * 86400)-benadering drift met ~6 uur per jaar.

Wat is het Y2038-probleem?

Een 32-bit signed integer Unix-timestamp overflowt op 03:14:07 UTC op 19 januari 2038. Systemen die nog 32-bit tijd gebruiken zullen overrollen naar een negatieve waarde (geïnterpreteerd als 13 december 1901). Modern Linux, Windows en macOS gebruiken allemaal 64-bit timestamps, wat goed is tot het jaar 292.277.026.596. Legacy embedded systemen zijn het blijvende risico.