Unix Timestamp Converter: Epoch to Human Date and Back
Paste a timestamp to read it as a date, or pick a date to get its timestamp. The tool detects seconds, milliseconds, microseconds and nanoseconds and shows UTC plus the time zone you choose
Timestamp and Date
Digits only; add a minus sign for dates before 1970. Editing either field updates the other. Valid range: about ±8.64 × 10¹⁵ milliseconds around 1970.
Unix time counts seconds since 1970-01-01 00:00:00 UTC and ignores leap seconds. The time zone only changes how the moment is displayed.
How to use this tool
- Paste a Unix timestamp, or press Use current time. The date field fills in at once.
- Leave the unit on Auto, or choose seconds, milliseconds, microseconds or nanoseconds.
- Pick a time zone and read the result in UTC and in that zone. To go the other way, edit the date and time and read the timestamp in all four units. Use Copy Result to keep it.
Worked example
The timestamp 1700000000 has 10 digits, so it is read as seconds: 2023-11-14T22:13:20Z in UTC. In America/Sao_Paulo (UTC−03:00 that day) the clock reads 19:13:20 on the same Tuesday, the 318th day of 2023. Add three zeros, 1700000000000, and the tool detects milliseconds and shows the identical moment. In the other direction, 2024-01-01 00:00:00 in UTC is 1704067200 seconds.
Methodology
The Linux manual defines Unix time as the number of seconds since the Epoch, 1970-01-01 00:00:00 UTC, and says Linux systems normally follow the POSIX requirement that this value ignore leap seconds (time(2) manual page). POSIX gives the arithmetic: every day counts as exactly 86400 seconds, so a timestamp is the days since the Epoch times 86400 plus the seconds into the day. JavaScript, which runs this tool, stores the same moment as milliseconds since the Epoch and accepts values up to ±8.64 × 10¹⁵ ms, from April 20, 271821 BC to September 13, 275760 AD (MDN). Dates are written in ISO 8601 form, using the profile defined in RFC 3339, with “Z” for UTC or an offset such as −03:00. Everything runs in your browser, and the time zone rules come from the browser’s own data, not from this site.
Four timestamp mistakes and how to spot them
Most wrong dates come from a few repeat causes. Check these before you debug anything else.
- Seconds read as milliseconds, or the reverse. 1700000000 taken as milliseconds is 1970-01-20, only 19 days after the Epoch, and 1700000000000 taken as seconds lands in the year 55840. A date near 1970 or in the far future usually means the wrong unit.
- Mixing up local time and UTC. A timestamp is one moment; the clock time comes from the zone. 1700000000 is 22:13:20 in UTC and 19:13:20 in São Paulo, and both are correct.
- Storing seconds in a signed 32-bit integer. The largest value, 2147483647, is 2038-01-19 03:14:07 UTC, and the smallest, −2147483648, is 1901-12-13 20:45:52 UTC. The time(2) manual page advises a wider time_t for software that must run after 2038.
- Expecting leap seconds. Unix time counts every day as 86400 seconds, so adding 86400 to a timestamp always gives the same UTC clock time one day later.
Frequently asked questions
What is a Unix timestamp? ▼
It is the number of seconds since 1970-01-01 00:00:00 UTC, the Unix Epoch, without counting leap seconds. For example, 1700000000 is 2023-11-14T22:13:20Z. Because it is one number for one moment, it is easy to store, sort and compare, and it does not depend on a time zone or a date format.
How can I tell if a timestamp is in seconds or milliseconds? ▼
Count the digits. Timestamps for dates around now have 10 digits in seconds, 13 in milliseconds, 16 in microseconds and 19 in nanoseconds. Auto mode applies that rule and shows what it detected. Very small numbers such as 1000 are ambiguous, so select the unit yourself when you know it.
What happens in 2038? ▼
2147483647 seconds, 2038-01-19 03:14:07 UTC, is the largest value of a signed 32-bit integer. Software that keeps seconds in 32 bits cannot hold the next second and can wrap around to a date in 1901. The Linux manual advises a wider time_t for software meant to run after 2038. This tool uses larger numbers, so it only warns you.
Does a Unix timestamp have a time zone? ▼
No. It identifies one moment for everyone on Earth. A time zone only decides which clock time you show for that moment: 1700000000 is 22:13:20 UTC and 19:13:20 in America/Sao_Paulo. When you edit the date field, the tool reads it in the selected zone.
Does Unix time include leap seconds? ▼
No. POSIX counts every day as exactly 86400 seconds and Linux follows that rule, so the count does not move for a leap second. Adding 86400 to a timestamp therefore always gives the same UTC clock time one day later, and this tool cannot show a 23:59:60 reading.