Unix timestamps explained

What a Unix timestamp is, how to tell seconds from milliseconds, how time zones affect display, why 2038 matters, and how to convert epoch time to dates.

What a Unix timestamp is

A Unix timestamp, also called epoch time or POSIX time, is the number of seconds that have passed since the Unix epoch: 00:00:00 UTC on 1 January 1970. For example, 1767225600 is 2026-01-01T00:00:00Z. Times before 1970 are negative numbers.

Timestamps are popular because they are simple. A single integer is easy to store, compare, sort and subtract, and it means the same instant everywhere in the world. Databases, log files, APIs, file systems and authentication tokens all use them.

The main alternative is an ISO 8601 string such as 2026-01-01T00:00:00Z. It is longer but readable at a glance, and it can carry an offset. Many APIs use ISO 8601 for clarity and timestamps for compactness; both identify the same instant, and converting between them is lossless apart from the precision you choose.

Seconds versus milliseconds

The classic Unix timestamp counts seconds. Many systems use milliseconds instead, including JavaScript's Date.now(), Java's System.currentTimeMillis() and many JSON APIs. Some databases and tracing systems use microseconds or nanoseconds. Mixing them up is one of the most common date bugs.

• Seconds: currently 10 digits, such as 1767225600.
• Milliseconds: currently 13 digits, such as 1767225600000.
• Microseconds: 16 digits. Nanoseconds: 19 digits.

If a date shows up in January 1970, a value in seconds was probably read as milliseconds. If it shows up tens of thousands of years in the future, milliseconds were read as seconds. To convert, multiply seconds by 1,000 or divide milliseconds by 1,000 and round down.

How to convert a timestamp to a date

1. Open the Unix timestamp converter. The current timestamp is shown at the top and updates every second.
2. Paste a timestamp in seconds or milliseconds, or a date such as 2026-01-01T12:00:00Z.
3. Read the results: Unix seconds, Unix milliseconds, ISO 8601, UTC, your local time and a relative time such as in 3 months.
4. Copy any value with its copy button.

The converter decides between seconds and milliseconds by size: numbers below 100 billion are read as seconds, and larger numbers as milliseconds. That covers seconds for dates up to the year 5138 and milliseconds for dates after early 1973, so in practice the guess is right for real-world values. Leaving the input empty shows the current time.

Time zones and timestamps

A Unix timestamp has no time zone. It identifies an instant, and that instant is the same in Tokyo and New York. Time zones only matter when you turn the instant into a calendar date and clock time for display. The timestamp 1767225600 is midnight on 1 January 2026 in UTC, but 7:00 PM on 31 December 2025 in New York.

• Store and transmit instants as timestamps or as ISO 8601 strings with a Z or an explicit offset, such as 2026-01-01T09:00:00+09:00.
• Convert to local time only at the edge, when showing a date to a person.
• Be careful with dates written without a zone. Different systems may read them as UTC or as local time, so add the zone whenever you can.
• For future events tied to a place, such as a meeting at 9:00 in Berlin, also store the time zone name, because daylight saving rules can change.

Leap seconds

Unix time pretends every day has exactly 86,400 seconds and ignores leap seconds. When a leap second occurs, the timestamp effectively repeats or stalls for a second. This keeps date arithmetic simple and rarely matters outside scientific and high-precision timing systems.

The year 2038 problem

Many older systems store Unix time in a signed 32-bit integer. The largest value it can hold is 2,147,483,647, which is 2038-01-19T03:14:07Z. One second later, the counter overflows to the most negative value and the date jumps back to 13 December 1901. This is the year 2038 problem.

Most modern operating systems, languages and databases now use 64-bit time values, which last for billions of years. The risk remains in embedded devices, old file formats, legacy databases with 32-bit integer columns and code that casts timestamps to 32-bit integers. If your software schedules or stores dates far in the future, such as 30-year loans or certificates, test with dates after 2038 now.

Common timestamp mistakes

• Storing milliseconds in a column or field that other code reads as seconds.
• Formatting a timestamp on a server in the server's local zone, then showing it to users in other zones.
• Comparing a local date string with a UTC timestamp, which shifts results by your zone offset.
• Adding 86,400 seconds to get the same clock time tomorrow. Across a daylight saving change, the local clock time moves by an hour; use a date library for calendar arithmetic.
• Truncating timestamps to 32-bit integers in databases, file formats or code.

Getting the current timestamp in code

• Shell (Linux and macOS): date +%s
• JavaScript: Math.floor(Date.now() / 1000) for seconds, or Date.now() for milliseconds.
• Python: int(time.time())
• PHP: time()
• SQL (PostgreSQL): SELECT extract(epoch FROM now());

Formatting timestamps for people

ISO 8601 dates are unambiguous for software, but people often need formats like 28 October 2026 or 10/28/2026. The date formatter turns a timestamp or date into any pattern using tokens such as YYYY, MM, DD, HH and mm, in local time or UTC. The tokens X and x output Unix seconds and milliseconds.

Timestamps in JWTs

JSON Web Tokens store exp, iat and nbf as Unix timestamps in seconds. When a token is rejected as expired, decoding it and converting those values is often the fastest way to find the cause. Our JWT decoder shows them as ISO 8601 dates automatically.