How to read Unix timestamps without doing math
Epoch seconds, milliseconds, ISO 8601 — the four formats every developer should be able to convert between, and what each one means.
You're looking at a log line that says created_at: 1735689600. Is that today? Last year? 1973? The Timestamp Converter turns numbers into readable dates in one paste.
The four timestamp formats
Unix epoch seconds. Seconds since January 1, 1970 UTC. The canonical Unix timestamp. As of 2026, ~1.76 billion. Will overflow a 32-bit signed integer in 2038 (the "Y2K38 problem") — everyone moved to 64-bit a decade ago, but legacy systems still bite occasionally.
Unix epoch milliseconds. Same thing × 1000. JavaScript's Date.now() returns this. Java's System.currentTimeMillis() too. As of 2026, ~1.76 trillion.
ISO 8601. A human-readable, machine-parseable date format. 2026-05-27T00:00:00Z. The T separates date from time. The Z (or +00:00) is the timezone offset. Always lexicographically sortable; always unambiguous.
Local time string. Whatever your locale formats dates as. The browser knows how to render "May 27, 2026 at 12:00 AM PDT" given an epoch and a locale.
The converter shows all four for every input. Paste an epoch, see the ISO. Paste an ISO, see the epoch.
The seconds-vs-milliseconds trap
The single biggest timestamp bug in any codebase is using seconds where milliseconds are expected, or vice versa. The two diverge by a factor of 1000 — a millisecond timestamp interpreted as seconds gives you a date 1000× too far in the future. A seconds timestamp interpreted as milliseconds gives you... 1970.
A heuristic that works: values below 10^12 (a trillion) are seconds. Values above 10^12 are milliseconds. This works for all reasonable timestamps from 1970 to 33658 AD. The converter uses this heuristic; you can override it explicitly if you have a small millisecond value that's ambiguous.
Time zones
Unix timestamps are timezone-independent. They count seconds since a specific moment in UTC, period. Display time zones are a presentation concern, not a storage concern.
The right pattern in any system:
- Store timestamps in UTC.
- Convert to local time only when displaying.
- Never store "wall clock" times without a timezone.
The converter shows ISO 8601 in UTC (the Z ending). The "Local time" row is whatever your browser is set to. If you need to compute "what time was that in Tokyo?" — open the converter in a Tokyo-timezone browser, or do the offset math.
Common one-shot conversions
- "When did this token expire?" Paste the
expvalue (seconds). The converter shows the ISO and local time. - "What's the Unix timestamp for next Monday at noon?" Type the ISO date. Copy the epoch.
- "Convert this log line." Most logs include ISO dates already. For numeric timestamps, paste and read.
The "now" buttons let you grab the current moment in seconds or milliseconds without thinking about which conversion you need.
What this isn't
- A date arithmetic tool. "What's the date 30 days from now?" is a separate calculation — use a date picker or do
Date.now() + 30 * 86400 * 1000in a JS console. - A duration formatter. "How many seconds in 3 hours and 15 minutes?" — also separate.
- A timezone converter. "What time is 9 AM Tokyo in New York?" — pick a dedicated timezone tool.
For "translate this timestamp into a date a human can read" — paste, glance, copy.