Unix timestamp converter

What is a Unix timestamp?

A Unix timestamp, also called epoch time or POSIX time, is the number of seconds since January 1, 1970 at 00:00:00 UTC. That moment is “the epoch”. One second later was 1, one day later was 86,400.

The same instant has the same timestamp everywhere on Earth. Time zones and daylight saving time only come into play when you turn the number back into a date for a person to read. That is why servers, databases, logs and APIs love it: one integer, no time zone, easy to sort and to subtract.

Seconds or milliseconds?

Most systems count seconds: today that is a 10-digit number. JavaScript, Java and many APIs count milliseconds: 13 digits. Some databases and tracing tools go down to microseconds (16 digits) or nanoseconds (19 digits).

The converter above reads the length of the number and picks the unit for you. If a date comes out in 1970 or far in the future, the unit was probably wrong: divide or multiply by 1,000.

The year 2038 problem

Many older systems store the timestamp in a signed 32-bit integer. The largest value it can hold is 2,147,483,647, which is January 19, 2038 at 03:14:07 UTC. One second later the counter overflows to −2,147,483,648, and those systems read the date as December 13, 1901 at 20:45:52.

Modern 64-bit systems are safe for billions of years. The risk sits in embedded devices, old file formats, databases with 32-bit columns and code that casts time to a 32-bit int. On Linux, 32-bit platforms gained 64-bit time support with kernel 5.6 in 2020 and glibc 2.34 in 2021, but software still has to be rebuilt to use it. A good test: try storing a date in 2040 and read it back.

Unix time and leap seconds

Unix time pretends every day has exactly 86,400 seconds. The real UTC clock has had 27 leap seconds added since 1972, the last one on December 31, 2016. During a leap second, Unix time usually repeats a second or stretches the seconds around it, a technique called smearing that some large cloud providers use. So a Unix timestamp is not a strict count of elapsed SI seconds: it is a count of days times 86,400, plus the seconds of the current day.

In practice this rarely matters, and it will matter less and less. In November 2022, the General Conference on Weights and Measures decided to raise the allowed gap between UTC and Earth’s rotation by 2035, which in effect ends leap seconds. The International Earth Rotation Service has already announced that no leap second will be added at the end of December 2026.

Time zones and daylight saving time

A timestamp names an instant, not a wall-clock time. At timestamp 1,700,000,000, it was 22:13 in London, 23:13 in Paris and 5:13 PM in New York: three local times, one number. When you store dates, keep the timestamp (or an ISO 8601 date with “Z”) and convert to local time only for display.

Daylight saving time shows why. On the night clocks fall back, the local hour from 1:00 to 2:00 AM happens twice, so a local time alone is ambiguous. The timestamps keep rising second by second without any jump. On the night clocks spring forward, a local hour is skipped, but no timestamp is missing.

Timestamp or ISO 8601?

ISO 8601 is the readable twin of the timestamp: 2023-11-14T22:13:20Z is the same instant as 1,700,000,000. A timestamp is compact and easy to compare; an ISO date is easy to read in a log or a JSON file. Both are unambiguous as long as the ISO date carries “Z” or an offset like +01:00.

How to get a Unix timestamp in code

// Current Unix time in seconds (Date.now() is in milliseconds)
Math.floor(Date.now() / 1000)

// Timestamp to date
new Date(1700000000 * 1000).toISOString()   // "2023-11-14T22:13:20.000Z"

// Date to timestamp
Date.UTC(2026, 0, 1) / 1000                  // 1767225600

import time
from datetime import datetime, timezone

int(time.time())                                       # current Unix time
datetime.fromtimestamp(1700000000, tz=timezone.utc)    # 2023-11-14 22:13:20+00:00
int(datetime(2026, 1, 1, tzinfo=timezone.utc).timestamp())   # 1767225600

time();                                   // current Unix time
gmdate('Y-m-d H:i:s', 1700000000);        // "2023-11-14 22:13:20"
strtotime('2026-01-01 00:00:00 UTC');     // 1767225600

-- MySQL (FROM_UNIXTIME uses the session time zone)
SELECT UNIX_TIMESTAMP();
SELECT FROM_UNIXTIME(1700000000);

-- PostgreSQL
SELECT EXTRACT(EPOCH FROM now())::bigint;
SELECT to_timestamp(1700000000);

-- SQLite
SELECT strftime('%s', 'now');
SELECT datetime(1700000000, 'unixepoch');

date +%s                              # current Unix time
date -u -d @1700000000                # Linux (GNU date)
date -u -r 1700000000                 # macOS and BSD
date -u -d '2026-01-01 00:00' +%s     # 1767225600 (GNU date)

Common pitfalls

• Local time by accident. Building a date from “2026-01-01 00:00” without a zone uses the computer’s local time. Add “Z” or “UTC”, or use the UTC switch above, when you mean UTC.
• Seconds passed as milliseconds. A 10-digit number read as milliseconds lands in January 1970. A 13-digit number read as seconds lands tens of thousands of years from now.
• Negative timestamps. Dates before 1970 are negative numbers: −86,400 is December 31, 1969. Most modern tools handle them, some older ones do not.

To see what time a timestamp is in another city, use the time zone converter. To count days between two dates, use the date calculator, and for durations in hours and minutes, the time calculator.