Unix Timestamp Explained: How to Convert Epoch Time to a Readable Date

A Unix timestamp, also called epoch time, is a count of the seconds that have passed since midnight UTC on 1 January 1970. It shows up constantly in logs, databases, API responses and spreadsheets because it is unambiguous and easy for computers to compare, and it is completely unreadable to a person. This guide explains what the number means, how to read and convert it, and the handful of mistakes (seconds vs milliseconds, time zones, the year 2038) that cause most timestamp bugs.

What the number means

The starting point, 1970-01-01 00:00:00 UTC, is called the Unix epoch. Everything is counted from there:

Dates before 1970 are negative numbers. A day is 86,400 seconds, which makes date arithmetic simple: add 86,400 to move forward exactly one day in UTC.

Why systems use epoch time instead of dates

A formatted date like 03/04/2026 is ambiguous: is it 3 April or 4 March? It also depends on a time zone, and some local times happen twice or never because of daylight saving changes. A timestamp has none of those problems. It is one number that means the same instant everywhere in the world, sorts correctly, compares with a simple greater-than, and takes very little storage. Standard practice is to store and transmit time as a timestamp (or as an ISO 8601 string in UTC) and convert to a local, human format only when displaying it.

Seconds vs milliseconds: the most common mistake

Some systems count seconds and others count milliseconds:

• Seconds (10 digits today): Unix and Linux, PHP, Python's time.time() (with decimals), most databases and most APIs.
• Milliseconds (13 digits today): JavaScript's Date.now(), Java's System.currentTimeMillis(), and many analytics and logging tools.

Mix them up and the date is absurd. Treat a millisecond value as seconds and you land tens of thousands of years in the future; treat seconds as milliseconds and you land in January 1970. If a converted date looks obviously wrong, count the digits first.

How to convert a timestamp

1. Open the Timestamp Converter.
2. Paste the epoch value. The tool recognises seconds or milliseconds by the number's size, so both 10-digit and 13-digit values convert correctly.
3. Read the date in your local time zone, or go the other way: pick a date and time to get its timestamp, for example to build test data or query an API.

Time zones: same instant, different clocks

A timestamp has no time zone. It marks one instant. What changes is how that instant is shown. The timestamp 1767225600 is midnight on 1 January 2026 in London, 05:30 that morning in India, and still 31 December 2025 at 19:00 in New York. All three are correct.

This explains a classic bug: a report that "loses" events at the edges of a day because it grouped timestamps by UTC date while users think in local dates. Decide which time zone your day boundaries belong to and convert before grouping. When sharing times in a bug report or with a team in other countries, share the timestamp or a UTC time, not your local clock.

Converting in code

• JavaScript: new Date(1767225600 * 1000).toISOString() (note the × 1000, because JavaScript expects milliseconds), and Math.floor(Date.now() / 1000) for the current time in seconds.
• Python: datetime.fromtimestamp(1767225600, tz=timezone.utc), and int(time.time()) for now.
• SQL (PostgreSQL): to_timestamp(1767225600), and extract(epoch from now()).
• Command line: date -d @1767225600 on Linux, date -r 1767225600 on macOS.
• Excel and Google Sheets: =A1/86400 + DATE(1970,1,1), then format the cell as a date. The result is in UTC.

The year 2038 problem

Older systems store timestamps as signed 32-bit integers, which can hold numbers up to 2,147,483,647. That is 03:14:07 UTC on 19 January 2038. One second later the counter overflows and wraps around to December 1901. Modern 64-bit systems are safe for billions of years, but embedded devices, old file formats and legacy databases with 32-bit time fields still exist, which is why 2038 appears in audits and software maintenance plans.

Leap seconds

Unix time pretends every day has exactly 86,400 seconds and ignores the leap seconds occasionally added to UTC. That keeps arithmetic simple, at the cost of a one-second ambiguity around those moments. It matters only for scientific and financial timing at sub-second precision, and leap seconds are scheduled to be abolished by 2035.

Frequently asked questions

What is the current Unix timestamp?

It changes every second. The Timestamp Converter shows it live, and in code it is Date.now() or time.time().

Can a timestamp be negative?

Yes. Negative values are dates before 1970. Not every system supports them, so test before relying on it.

Why does my converted time look a few hours off?

Almost always a time zone display difference: one tool shows UTC and another your local time. The underlying instant is the same.

Should I store timestamps or date strings?

Either works if you are consistent. Timestamps or UTC ISO 8601 strings (2026-01-01T00:00:00Z) are both safe. Avoid storing local times without a zone.