Unix timestamps power nearly every computer system on earth — from database records to JWT tokens. Yet they are notoriously opaque to humans: what does 1708387200 mean at a glance? A Unix Timestamp Converter instantly translates these numbers into meaningful dates, and vice versa.
What Is a Unix Timestamp?
A Unix timestamp (also called epoch time or POSIX time) is the number of seconds that have elapsed since the Unix Epoch: January 1, 1970, 00:00:00 UTC.
It was chosen as a reference point because it coincided with the development of Unix at Bell Labs. The epoch itself is a fixed, timezone-independent moment in time that any system in the world can use as a common reference.
Unix Epoch: 1970-01-01 00:00:00 UTC = timestamp 0
1 hour later: timestamp 3600 (60 x 60)
1 day later: timestamp 86400 (60 x 60 x 24)
1 year later: timestamp 31536000 (approximately)
Today (~Feb 2026): timestamp = approx. 1740000000Seconds vs. Milliseconds: A Common Source of Bugs
One of the most frequent timestamp bugs in web development: confusing second-precision and millisecond-precision timestamps.
- Unix timestamps are traditionally in seconds. 10 digits. Example:
1708387200 - JavaScript's Date.now() returns milliseconds. 13 digits. Example:
1708387200000 - Java's System.currentTimeMillis() — also milliseconds.
- Python's time.time() — seconds (float).
time.time_ns()returns nanoseconds.
# Python
import time
ts_seconds = int(time.time()) # 1708387200
ts_ms = int(time.time() * 1000) # 1708387200000
# JavaScript
const tsMs = Date.now(); // milliseconds
const tsSec = Math.floor(Date.now() / 1000); // seconds
# Common bug: passing ms timestamp to a function expecting seconds
# Result: dates showing year 55,000+ instead of 2026When you see a timestamp with 13 digits, it is almost certainly milliseconds. 10 digits means seconds. If you get a year far in the future or far in the past, the first thing to check is whether you are mixing up the two.
Epoch Time and Timezones
Unix timestamps are always UTC. They have no timezone embedded in them. When you convert a timestamp to a human-readable date, you must choose a timezone — and that choice determines the displayed date and time.
# Timestamp 1708387200 (Feb 19, 2026 16:00:00 UTC)
UTC: 2026-02-19 16:00:00
US/Eastern: 2026-02-19 11:00:00 (UTC-5 in February)
US/Pacific: 2026-02-19 08:00:00 (UTC-8 in February)
Europe/Berlin: 2026-02-19 17:00:00 (UTC+1 in February)
Asia/Tokyo: 2026-02-20 01:00:00 (UTC+9) — different DATE!This is why timestamp comparisons should always be done in UTC. Displaying to users should use their local timezone. Storing in databases should use UTC or the raw timestamp.
Converting Timestamps in Code
# Python: timestamp to datetime
from datetime import datetime, timezone
ts = 1708387200
dt = datetime.fromtimestamp(ts, tz=timezone.utc)
print(dt.isoformat()) # 2026-02-19T16:00:00+00:00
# Python: datetime to timestamp
dt = datetime(2026, 2, 19, 16, 0, 0, tzinfo=timezone.utc)
ts = int(dt.timestamp()) # 1708387200
# JavaScript: timestamp to Date
const ts = 1708387200;
const d = new Date(ts * 1000); // multiply by 1000 for ms
console.log(d.toISOString()); // "2026-02-19T16:00:00.000Z"
# JavaScript: Date to timestamp (seconds)
const ts = Math.floor(new Date('2026-02-19T16:00:00Z').getTime() / 1000);
# SQL (PostgreSQL): timestamp to human date
SELECT to_timestamp(1708387200);
# SQL: human date to timestamp
SELECT EXTRACT(EPOCH FROM '2026-02-19 16:00:00+00'::timestamptz)::bigint;The Year 2038 Problem
32-bit signed integers can store timestamps up to 2,147,483,647, which corresponds to January 19, 2038, 03:14:07 UTC. After that, a 32-bit timestamp overflows to a large negative number, causing systems to display dates in 1901.
Modern systems use 64-bit integers, which push the overflow problem to the year 292,277,026,596. But embedded systems, legacy databases (MySQL's older TIMESTAMP type), and old C code using time_t as 32-bit may still be vulnerable. If you are maintaining legacy systems, this is worth auditing.
Common Timestamp Formats
- Unix timestamp:
1708387200— seconds since epoch, UTC - ISO 8601:
2026-02-19T16:00:00Z— human-readable, timezone-explicit - RFC 2822:
Thu, 19 Feb 2026 16:00:00 +0000— used in email headers - REST API:
Thu, 19 Feb 2026 16:00:00 GMT— used in HTTP headers (Cache-Control, Last-Modified)
Convert Timestamps Instantly
Our free Unix timestamp converter converts in both directions — paste a timestamp and get the human-readable date in UTC and your local timezone, or enter a date and get the epoch timestamp. Handles both seconds and milliseconds automatically.