Unix Timestamp Converter (Epoch to Date)

What a Unix timestamp actually counts

A Unix timestamp is a count of seconds since 1 January 1970 at 00:00:00 UTC, the moment everyone calls the epoch. There is nothing else in it. No time zone, no calendar rules, no locale — just a number on a line that stretches forwards and backwards from that instant.

The part that catches people out is leap seconds. POSIX time defines every day as exactly 86,400 seconds, so the roughly two dozen leap seconds added to civil time since 1972 do not appear in the count. When one is inserted, a timestamp either repeats a value or skips, depending on how the system smears it. The upside is that converting a timestamp to a date is pure arithmetic with no lookup table. The cost is that a Unix timestamp cannot name a leap second at all.

Seconds or milliseconds

Unix tools, most SQL databases and a lot of APIs count whole seconds. JavaScript, Java and anything derived from them count milliseconds. Go and some tracing systems use nanoseconds. All of them are called "the timestamp" in documentation, which is how the bug gets in.

Length is the quickest tell for any date near the present. Ten digits is seconds, thirteen is milliseconds, sixteen is microseconds, nineteen is nanoseconds. Those lengths are stable for a long time: a seconds timestamp stayed at ten digits from September 2001 and will until 2286.

The failure mode is loud in one direction and quiet in the other. Feed milliseconds to something expecting seconds and you land tens of thousands of years in the future, which somebody will notice. Feed seconds to something expecting milliseconds and you land in January 1970 — a plausible-looking wrong answer that quietly sorts to the top of every list. If a date in your app shows 1970, you are off by a factor of 1000.

The 2038 problem

A signed 32-bit integer runs out at 2,147,483,647 seconds, which is 03:14:07 UTC on 19 January 2038. One second later it wraps to a negative number and the date reads December 1901.

Your laptop is not the worry. The 32-bit value survives in embedded firmware, in old C code that was never recompiled, in file formats, and in database columns: MySQL's TIMESTAMP type is still capped at that same 2038 instant, while DATETIME is not. If you store a mortgage end date or a certificate expiry in a 32-bit field, the bug is already in your data.

A timestamp has no time zone

This is worth saying twice, because it causes more incident reports than 2038 ever will. A timestamp identifies an instant. The time zone is applied when you display it, not when you store it. Two people reading the same timestamp in Tokyo and Lisbon see different wall clocks and neither is wrong.

The classic mistake is going the other way: taking the digits off a local clock, calling mktime or its equivalent without the offset, and storing the result. That stores an instant that is off by the offset, and the error changes twice a year when daylight saving moves. If the value came from a user's calendar rather than from a clock, store the zone name alongside it — "09:00 in Europe/Madrid" and "an instant" are different facts.

Where this converter stops

• Two zones only. You get your device zone and UTC. There is no zone picker, so converting to a third city means doing it in your head.
• Sub-millisecond input is truncated. Browser dates have millisecond resolution, so the last three digits of a microsecond timestamp and the last six of a nanosecond one are dropped, not rounded.
• Range. Anything beyond about 8.64 × 10¹⁵ milliseconds from the epoch is rejected, which is the year -271821 to 275760.
• Old dates drift. Local time before 1970 depends on historical zone data your browser may not carry in full, so pre-1970 local times can be an hour or a few minutes out. The UTC line is always right.
• The clock is your device's. The "right now" figures are only as accurate as the machine you are sitting at.

Last updated September 19, 2026