How to Convert Epoch Unix Time to a Readable Date

The Unix epoch is the fixed origin: 1970-01-01T00:00:00Z. Unix time (also called epoch time or POSIX time) is the elapsed duration from that origin, usually as an integer.

• 0 → the epoch itself in UTC
• 1000000000 → 2001-09-09T01:46:40Z (seconds)
• Negative values → times before 1970 (supported in many modern systems)

The number itself is timezone-agnostic. It names an instant. Displaying “3:00 PM in New York” or “noon in London” is a formatting choice on top of that instant.

Why APIs love it

JSON can ship "created_at": 1720000000 without locale ambiguity. Clients convert for UI; servers compare integers for ranges. JWT exp and iat claims are typically Unix seconds — decode the payload with a JWT decoder, then convert those claims here if you want wall-clock times.

Open the free epoch converter to see the current live stamp next to human-readable forms.

This is the number-one conversion error. The same calendar day looks like garbage if you treat ms as seconds (or the reverse).

Form	Typical digits (now-ish)	Example order of magnitude
Seconds	~10 digits	1.7 × 109
Milliseconds	~13 digits	1.7 × 1012
Microseconds	~16 digits	1.7 × 1015

What goes wrong

• ms interpreted as seconds — dates land centuries in the future
• seconds interpreted as ms — dates land near January 1970 (a few thousand seconds after epoch)

Rule of thumb: if the absolute value is greater than about 10¹², you are probably looking at milliseconds (for dates near the present). If it is around 10⁹, it is probably seconds. Good converters auto-detect; still verify when the value is a duration or a year-2038 edge case.

JavaScript’s Date.now() returns milliseconds. Many Unix shells print seconds with date +%s. Never mix them in the same column without a unit label.

One epoch value maps to one instant. Multiple strings can describe it:

• UTC — clock in Coordinated Universal Time (often written with Z)
• Local — clock in your browser or OS timezone, including DST rules
• ISO 8601 — standardized string such as 2026-08-03T15:30:00.000Z

Same instant, different faces

Suppose the epoch seconds convert to 2026-08-03T18:00:00Z. In America/New_York (EDT, UTC−4) that local clock may show 2:00 PM on the same calendar date. In Tokyo (UTC+9) it may already be 3:00 AM on August 4. The epoch number did not change; the zone offset and day boundary did.

When you only need zone-to-zone wall times without digging into raw stamps, pair this with a timezone converter. When you need stamp ↔ date both ways in a similar workflow, also see the timestamp converter guide.

A live clock shows “what is Unix time right now?” while you compare log lines. If your log says 1722680000 and the live clock is near 1722680500, you know that event was about 500 seconds (~8.3 minutes) ago — no mental calendar math required.

Relative checks

• Future exp — JWT expiry should be greater than “now” in the same unit
• Stale cache — stored epoch + TTL < now → expired
• Clock skew — server “now” vs your laptop “now” off by minutes can break tight auth windows

Paste suspicious values into the converter instead of guessing. If two services disagree by exactly factor of 1000, one is almost certainly using ms and the other seconds.

Readable → epoch is the reverse path: pick a calendar date and time, declare its timezone (or treat as UTC), then compute seconds or milliseconds since 1970-01-01T00:00:00Z.

1. Write the instant in ISO form with offset, e.g. 2026-08-03T12:00:00-04:00.
2. Normalize to UTC internally.
3. Count seconds (or ms) from the epoch.
4. Store or send the integer your API expects.

API and logging tips

• Document units in the field name: created_at_ms vs created_at (seconds)
• Prefer UTC in storage; convert for display only
• When payloads are Base64 (e.g. parts of tokens), decode first with a Base64 encoder/decoder, then convert any epoch fields you find

Ambiguous local strings like “08/03/2026 3:00 PM” without a zone are a bug factory. Always attach an offset or zone id when humans type dates that will become epoch values.

Paste a stamp to get dates, or enter a date to get a stamp. Check seconds vs ms and read UTC and local side by side.

1. Open the free epoch converter.
2. Note the live current timestamp for a baseline “now.”
3. Paste a Unix value from a log, database, or API.
4. Confirm whether the tool treated it as seconds or milliseconds.
5. Read ISO, UTC, and local outputs for that instant.
6. To go the other way, enter a date/time and generate epoch seconds or ms.
7. Compare two stamps by converting both and subtracting (or compare to live now).
8. Fix unit mismatches in code once you see the off-by-1000 pattern.

Debugging workflow

Keep the converter tab next to your terminal. Convert the first and last timestamp in a failing window so you know the real duration of the incident in local time for the on-call write-up.

Most bad dates come from units and zones, not from “hard math.”

• Seconds vs milliseconds mix-ups (factor of 1000)
• Assuming the stamp contains a timezone — it does not
• Formatting in local time but labeling the string as Zulu (Z)
• 32-bit overflow fears — year 2038 matters for old 32-bit time_t; use 64-bit or ms carefully in long-lived systems
• Parsing ISO without offset and assuming UTC in one language and local in another

For related workflows: timestamp conversion, timezone conversion, JWT decoding, and Base64 decoding.

This guide is educational. Leap seconds and obscure historical TZ rules rarely affect day-to-day API work, but unit and zone mistakes do every week.