Encoders & Utilities

Unix Timestamp & Date Calculator

Convert Unix epochs to human dates, calculate date arithmetic, and measure differences between dates.

UTC

Local

Unix

Unix timestamp Unit Timezone

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

Mode

About this tool

Unix Timestamp & Date Calculator converts between integer Unix epochs and ISO 8601 / locale-formatted dates in both directions. Paste a number and it tells you whether you fed it seconds (10 digits), milliseconds (13 digits), microseconds (16), or nanoseconds (19) — and renders the corresponding date in UTC, your local time zone, and any time zone you pick from the IANA list. Going the other way, paste a date string in any common format and get the epoch.

A second mode handles date arithmetic: add or subtract days, hours, minutes from a base date; compute the difference between two dates as days/hours/minutes/seconds (or "3 years, 2 months, 14 days" if you prefer calendar units). All math runs in the browser using Temporal where available and a fallback library otherwise — no time-zone surprises from DST transitions, leap seconds (ignored, like in Unix time itself), or the 2038 rollover (we handle 64-bit timestamps natively).

When to use this tool

Debugging logs. A log entry with epoch 1747459200 — paste it, see "May 17, 2026 04:00 UTC", done.
Database date sanity checks. Verify a value stored as BIGINT ms actually decodes to the expected human date.
SLA / cron arithmetic. "What is 72 hours from now in Tokyo time?" — answered in two clicks.
Token expiry. A JWT's exp claim is an epoch — paste it here for the human-readable answer.

About the 2038 problem

32-bit signed Unix timestamps overflow at 03:14:07 UTC on 19 January 2038 (the "Y2038" bug). The fix is to use 64-bit timestamps, which most modern languages and databases default to today. Our calculator uses 64-bit internally — values past 2038, and well beyond the year 100,000, are computed correctly. Legacy systems on embedded hardware are the remaining exposure surface.

Frequently asked questions

Why is my "timestamp" 13 digits long?

It is in milliseconds, not seconds. JavaScript, Java, and many newer APIs default to millisecond resolution; classical Unix is seconds. 10 digits = seconds (current era through 2286), 13 digits = milliseconds, 16 digits = microseconds, 19 digits = nanoseconds. Our parser detects the precision by digit count and converts accordingly.

Does the tool handle time zones correctly?

Yes — every conversion shows UTC alongside the time zone you pick (defaults to your browser's local zone). Daylight-saving transitions are honoured for IANA zones (e.g. "Europe/Berlin" handles CET/CEST shifts automatically). Be cautious with fixed-offset strings ("+02:00") — they look the same on a normal day but ignore DST.

Why is my year-arithmetic answer different from a simple division?

Because calendar units are uneven. A "year" averages 365.2425 days; some are 365, some are 366. Subtracting two dates in "years and months" requires real calendar walking, not just dividing seconds. Our tool does the walk; a simple seconds / (365 * 86400) approximation drifts by ~6 hours per year.

What is the Y2038 problem?

A 32-bit signed integer Unix timestamp overflows at 03:14:07 UTC on January 19, 2038. Systems still using 32-bit time will roll over to a negative value (interpreted as 13 December 1901). Modern Linux, Windows, and macOS all use 64-bit timestamps, which is good until the year 292,277,026,596. Legacy embedded systems are the lingering risk.