Unix Timestamp Converter (Epoch to Date)

Convert Unix timestamps (epoch seconds or milliseconds) to readable dates and back. See UTC and local time side by side, plus ISO 8601, weekday and relative time.

What is a Unix timestamp?

A Unix timestamp, also called Unix time, POSIX time or epoch time, is the number of seconds that have passed since 00:00:00 UTC on 1 January 1970. That reference moment is called the Unix epoch. The count is the same number everywhere on Earth at the same instant, which is why databases, log files and APIs store time this way instead of storing a formatted date string.

Because it is a plain integer, a timestamp is easy to compare and sort: a larger number is always a later moment. It also carries no time zone and no daylight-saving rules, so it can never be ambiguous the way 2026-03-29 02:30 is in a country where the clocks jump forward at that hour.

Seconds or milliseconds? How to tell them apart

The same instant has two common spellings, and mixing them up is the most frequent timestamp bug of all. Counting digits is the quick check:

10 digits, for example 1789689600 - seconds. That range covers 2001 to 2286.
13 digits, for example 1789689600000 - milliseconds. Same instant, three extra zeros.

The Unix and POSIX definition counts seconds. JavaScript counts milliseconds: Date.now() returns milliseconds, and so does new Date().getTime(). Java does the same with System.currentTimeMillis(). Python's time.time() and PHP's time() return seconds, and so does date +%s on Linux and macOS.

This converter auto-detects the unit with one rule: a value below 100,000,000,000 is read as seconds, anything larger as milliseconds. The reasoning is that 100,000,000,000 seconds is the year 5139 while 100,000,000,000 milliseconds is 1973, so no realistic timestamp sits on the wrong side of that line. If a date looks wrong by a factor of a thousand, force the unit by hand and read it again.

Why the same timestamp shows two different dates

A timestamp is an instant, not a calendar date. 1789689600 is 18 September 2026 in UTC, but in Los Angeles it is still 17 September, because that city sits seven hours behind. Neither reading is wrong; they describe the same moment in different offsets. That is why this page always shows the UTC value and your local value next to each other.

A related trap lives in JavaScript date parsing. A date-only string is read as UTC, while a date-and-time string with no offset is read as local time:

new Date('2026-09-18') is midnight UTC.
new Date('2026-09-18T00:00') is midnight in the visitor's own time zone.

Those two values differ by your offset, which is why a daily report built on the first form can land on the previous day for every visitor west of UTC. If local midnight is what you mean, write the time part too.

The Year 2038 problem

A signed 32-bit integer tops out at 2,147,483,647. Read as Unix seconds, that is 19 January 2038 at 03:14:07 UTC. Systems that still store time in a 32-bit field overflow one second later and wrap around to December 1901, which is why embedded devices, old database columns and some file formats are being migrated to 64-bit timestamps. Paste 2147483647 above to see the boundary itself.

How to use this converter

Paste a timestamp into the first box. The unit is detected for you and every format below updates at once.
Read the table: Unix seconds and milliseconds, ISO 8601 in UTC and in your local offset, the UTC string, a readable local time, the weekday, the day of the year and the ISO week number.
Use the Copy button on any row. The values are plain text, so they paste cleanly into a ticket, a log file or a spreadsheet.
To go the other way, pick a date and time in the second card, say whether you mean your local time or UTC, and the timestamp appears in the same table.
Use Today 00:00 UTC when you need the start of the current UTC day, which is the usual way to build daily buckets.

Unix time tips and gotchas

Store UTC, display local. Keep timestamps, or ISO 8601 strings with an explicit offset, in your database and convert only when you render. Storing a local wall-clock time as if it were UTC is the origin of most "the report is one day off" complaints.
Leap seconds are not counted. Unix time assumes every day is exactly 86,400 seconds, so the 27 leap seconds added since 1972 do not appear in it. That only matters when you compare against TAI or need sub-minute astronomical accuracy.
Negative timestamps are valid. They point to instants before the epoch, such as -86400 for 31 December 1969.
Prefer ISO 8601 for anything human-readable. 2026-09-18T07:30:00Z carries its own offset, sorts correctly as text as long as the offset never changes, and is unambiguous to a reader in any country.
Watch the week number. An ISO week belongs to the year that owns its Thursday, so 1 January can fall in week 52 or 53 of the previous year. Both values are shown in the table above.

FAQ

Is a Unix timestamp in seconds or milliseconds?

The Unix or POSIX definition uses seconds. JavaScript (Date.now()) and Java (System.currentTimeMillis()) use milliseconds. A 10-digit value such as 1789689600 is almost always seconds, and a 13-digit value such as 1789689600000 is almost always milliseconds. This converter detects the unit automatically and lets you force either one.

Why does my timestamp show a different date than I expected?

A Unix timestamp has no time zone: it is one instant, and the calendar date you see depends on the offset you read it in. 1789689600 is 18 September in UTC but 17 September in Los Angeles. This page always shows the UTC value and your local value side by side so the difference is visible instead of surprising.

What is the Year 2038 problem?

A signed 32-bit integer can hold Unix times only up to 2,147,483,647, which is 19 January 2038 at 03:14:07 UTC. Systems that still store time that way will wrap around to December 1901. Modern 64-bit timestamps are not affected and will keep working for around 292 billion years.

Does Unix time count leap seconds?

No. Unix time assumes every day is exactly 86,400 seconds, so the 27 leap seconds added since 1972 are simply not represented. That is why Unix time and UTC have drifted apart by about 27 seconds, which matters only for sub-minute comparisons against TAI or astronomical time, not for ordinary timestamps.

How do I get the current Unix timestamp?

The live clock at the top of this page shows it. On the command line, date +%s returns seconds on Linux and macOS. In code, use Date.now() in JavaScript (milliseconds), time.time() in Python (seconds as a float), or time() in PHP (seconds).