Convert Unix epoch timestamps to human-readable dates and back. Auto-detects seconds vs. milliseconds.
Unix time (also known as Epoch time or POSIX time) is the number of seconds that have elapsed since 00:00:00 UTC on January 1, 1970 — the Unix epoch. It does not count leap seconds.
Seconds vs. Milliseconds: Traditional Unix timestamps are in seconds (10 digits until 2286). Many systems (JavaScript, Java) use milliseconds (13 digits). This converter auto-detects the format.
Why use Unix timestamps? They provide a timezone-independent, integer-based representation of time — ideal for databases, APIs, and log files. No timezone ambiguity. No DST confusion. Simple comparison with > and < operators.
| 1 second | 1 |
|---|---|
| 1 minute | 60 |
| 1 hour | 3,600 |
| 1 day | 86,400 |
| 1 week | 604,800 |
| 1 year (365 days) | 31,536,000 |
A Unix timestamp is a signed integer. When that integer is 32 bits wide, it can hold values up to 2,147,483,647 — which corresponds to 2038-01-19 03:14:07 UTC. One second later the value overflows, wraps to a large negative number, and the same clock reads 1901-12-13.
This is not a hypothetical about ancient hardware. time_t is 32 bits on any system built with a 32-bit ABI, which includes plenty of long-lived embedded controllers, industrial equipment, and routers still in service. MySQL's TIMESTAMP column type uses a 4-byte integer internally, so its documented range ends at the same moment — a row holding a date past January 2038 cannot be represented in that type at all.
The second-based format itself is not the constraint. Ten digits carry you to 2286, and switching to 64-bit integers extends the range by a factor no application will ever exhaust. The failure is entirely about signed width: the same value in a 64-bit integer is simply a date in 2038.
POSIX time defines every day as exactly 86,400 seconds. Earth's rotation does not cooperate with that definition, so civil timekeeping inserts leap seconds to stay aligned with the Sun — 27 of them since 1972, most recently at the end of 2016.
Because Unix time refuses to count them, it drifts from UTC by the accumulated total, currently 37 seconds once you include the initial offset. Different systems paper over this differently: some repeat the final second of the day, so the timestamp 1483228799 can occur twice and two distinct events share a numeric value; others smear the extra second across a window — Google spreads it over 20 hours, so time runs imperceptibly slow rather than jumping.
For an application that stores timestamps and sorts them, none of this is usually visible. It becomes visible when you require strict monotonicity or when you assume a fixed number of seconds between two dates across a leap-second boundary. In 2022 the international metrology bodies agreed to stop inserting leap seconds by 2035, which removes the source rather than solving the arithmetic — the 37-second offset will simply remain.
Converting in the other direction — string to timestamp — is less uniform than it looks, and the differences are specified rather than accidental.
A date-only string is parsed as UTC. Per the ECMAScript specification, new Date("2026-09-15") is midnight UTC. For anyone west of Greenwich that renders as September 14 in local time, so a date picked from a calendar and round-tripped through a timestamp can come back as the previous day. Attaching a time and an offset — "2026-09-15T00:00:00-05:00" — removes the ambiguity.
Month numbers start at zero. In new Date(2026, 8, 15) the 8 means September, not August. This constructor form is not affected by string parsing rules at all, which is why the two mistakes are often found in the same file.
Seconds and milliseconds are different units. Date.now() returns milliseconds, and Unix timestamps conventionally mean seconds, so the conversion divides by 1000 and must floor rather than round — rounding turns a timestamp into the following second roughly half the time, which is enough to break an equality check.
The durable fix is a storage rule rather than a parsing trick: persist UTC (as an integer or as ISO 8601 with an explicit Z), store the IANA timezone separately, and format for display at the edge. Never store a local wall-clock time without the zone it belongs to.
See also: Timezone Converter · ISO 8601 Formatter · UUID Generator · Timestamp Tools