Fast, practical, browser-based developer tools
Convert Unix timestamps into readable dates and convert dates back into Unix timestamps instantly. This browser-based timestamp converter supports epoch seconds, milliseconds, local time, UTC, and ISO output.
Unix timestamps are common in logs, APIs, databases, analytics, and event tracking. This page helps inspect and convert them quickly without using a terminal, script, or external tool.
Timestamp conversion is often needed when debugging backend responses, checking event times, reading system logs, or validating time-based application data.
For more details about site usage and analytics, read our Privacy Policy.
Enter a Unix timestamp to convert it into readable time formats, or choose a date and time to convert it into Unix seconds and milliseconds. You can also load the current time instantly.
Input: 1700000000 Local: Tue Nov 14 2023 22:13:20 GMT+0000 UTC: Tue, 14 Nov 2023 22:13:20 GMT ISO: 2023-11-14T22:13:20.000Z
A Unix timestamp is the number of seconds elapsed since the Unix epoch:
1970-01-01 00:00:00 UTC. The critical detail people skip is that it is
anchored to UTC, not local time. By itself a timestamp represents a single
instant with no timezone attached — the same moment is one identical number
everywhere on Earth.
Timezone only enters the picture when you format the instant for a human to read. That is why the same value can display as one wall-clock time in New York and another in Tokyo while remaining a single number underneath. Storing and transmitting the bare number, and applying a timezone only at display time, is what makes epoch time so convenient to compare and sort.
The most common timestamp bug is a units mismatch. Traditional Unix timestamps are counted
in seconds — a 10-digit number today, and it stays 10 digits until the
year 2286. JavaScript is the odd one out: Date and Date.now()
work in milliseconds, which is 13 digits.
Cross the boundary without converting and the failure is dramatic. Pass a
seconds value into new Date(value), which expects milliseconds, and
you land in January 1970 — the number is treated as a few hundred million milliseconds
after the epoch, i.e. a couple of weeks in. Pass a milliseconds value to a
seconds-based API and you get a date tens of thousands of years in the future. The rule of
thumb: roughly 10 digits means seconds, 13 digits means milliseconds, and
you multiply or divide by 1000 at the boundary. (This tool inspects the digit length and
treats 13-or-more-digit input as milliseconds for exactly this reason.)
Any system that stores time in a signed 32-bit integer can only count up
to 2,147,483,647 seconds after the epoch. That ceiling is reached at
03:14:07 UTC on 19 January 2038. One second later the counter overflows and
wraps to a large negative number, throwing the date back to 1901 — the epoch equivalent of
the Year 2000 bug, sometimes called the "Y2038" or "Epochalypse" problem.
It is not just a historical curiosity. It affects legacy C time_t values, some
embedded and industrial devices that will still be running in 2038, and any database column
or protocol field that stores time as a 32-bit integer. The fix is to store time in
64 bits, which pushes the overflow roughly 292 billion years out; languages
and platforms that already use 64-bit or millisecond time are unaffected. Auditing your
stack for surviving 32-bit epoch fields is the real action item.
These two are constantly conflated, and the difference causes real bugs. A UTC
offset such as +05:30 or -05:00 is just a fixed number of
minutes from UTC. A timezone such as America/New_York — an
entry in the IANA/tz database — is a full rule set: it includes daylight-saving
transitions, the dates they happen, and historical changes to those rules.
The offset -05:00 tells you nothing about whether daylight saving applies next
month; New York is -05:00 in winter and -04:00 in summer. Store a
bare offset and treat it as a zone, and every calculation that crosses a DST boundary drifts
by an hour. For a future event — a meeting, a reminder, a scheduled job — store the full
IANA zone name (or plain UTC), never just an offset, so the DST rules are
applied correctly when the moment actually arrives.
Unix time makes a deliberate simplification: it assumes every day is exactly 86,400 seconds long. Real UTC does not work that way. Since 1972, 27 leap seconds have been inserted to keep clocks aligned with the Earth's gradually slowing rotation. Unix time skips all of them.
Two consequences follow. First, a Unix timestamp is not a true count of elapsed SI seconds since 1970 — it is short by the number of leap seconds inserted since then. Second, during an inserted leap second the value is ambiguous and effectively repeats. Because a hard one-second jump breaks distributed systems, large platforms like Google and AWS "smear" the leap second — spreading it across a whole day so clocks never skip. The practical rule: Unix timestamps are excellent for ordering and everyday time, but do not rely on them for precise physical interval measurement.
Count the digits. A present-day timestamp in seconds has about 10
digits; in milliseconds it has about 13. Traditional Unix APIs use
seconds, while JavaScript's Date uses milliseconds, so you multiply or
divide by 1000 when moving between them.
You almost certainly passed a seconds value to an API that expects
milliseconds, such as new Date(1700000000). Interpreted
as milliseconds, that is only about three weeks after the epoch, so it lands in January
1970. Multiply the seconds value by 1000 first.
Systems that store time in a signed 32-bit integer overflow at
03:14:07 UTC on 19 January 2038, when the count exceeds
2,147,483,647 and wraps to a negative number, jumping the date back to
1901. It affects legacy C time_t, some embedded devices, and 32-bit time
fields in databases and protocols. The fix is 64-bit time storage.
No. An offset like -05:00 is a fixed number of minutes; a timezone like
America/New_York is a rule set that includes daylight-saving transitions
and historical changes. An offset can't tell you whether DST applies next month, so for
future events store the full IANA zone name (or UTC), never just an offset.
No. Unix time assumes every day is exactly 86,400 seconds and ignores the 27 leap seconds inserted into UTC since 1972, so it is not a true count of elapsed SI seconds and is ambiguous during an inserted leap second. Big platforms "smear" the leap second across a day instead of inserting it. Don't use Unix timestamps for precise physical interval measurement.
No. It is a single UTC-anchored instant — the same number worldwide, with no timezone attached. A timezone is applied only when you format the value for a human to read, which is why one timestamp can display as different local times in different regions.