What is a Unix timestamp?
A Unix timestamp (also called Unix time, POSIX time, or epoch time) is the number of seconds that have elapsed since January 1, 1970, 00:00:00 UTC. This reference point is called the "Unix epoch."
As of June 2026, the current Unix timestamp is approximately 1,748,822,400. Every second, this number increases by 1.
Unix timestamps are timezone-independent by design — they always measure seconds from the UTC epoch. When you convert to a human-readable date, timezone conversion is a separate step.
Convert any Unix timestamp to a human-readable date with the free Unix timestamp converter.
Why January 1, 1970?
Unix was developed at Bell Labs in the late 1960s. When the development team needed a reference point for time, they chose January 1, 1970 — a recent, round date that was near the start of the Unix development era. The choice was somewhat arbitrary, but it has been the standard for all Unix-derived systems (Linux, macOS, iOS, Android) ever since.
Windows uses a different epoch: January 1, 1601 (the start of a 400-year Gregorian calendar cycle). The .NET DateTime type also uses 1601. This is why converting timestamps between Windows and Unix systems requires adding or subtracting the difference (11644473600 seconds).
Milliseconds vs. seconds
A critical distinction: some systems store Unix timestamps in seconds (13 digits in 2026 — e.g., 1748822400), and others store them in milliseconds (16 digits — e.g., 1748822400000).
JavaScript's Date.now() returns milliseconds. Most Unix system calls and APIs return seconds. If you see an unusually large timestamp (16 digits) or an unusually small one (10 digits) when you expected the other, this is usually the cause.
Quick check in JavaScript:
// Seconds (10 digits in 2026)
Math.floor(Date.now() / 1000) // → 1748822400
// Milliseconds (13 digits in 2026)
Date.now() // → 1748822400000Converting Unix timestamps in code
In JavaScript:
// Timestamp to readable date
const timestamp = 1748822400;
const date = new Date(timestamp * 1000); // convert seconds to ms
console.log(date.toISOString()); // "2025-06-02T00:00:00.000Z"
console.log(date.toLocaleDateString()); // locale-dependent format
// Current timestamp (seconds)
const now = Math.floor(Date.now() / 1000);In Python:
from datetime import datetime, timezone
timestamp = 1748822400
dt = datetime.fromtimestamp(timestamp, tz=timezone.utc)
print(dt.isoformat()) # "2025-06-02T00:00:00+00:00"
# Current timestamp
import time
now = int(time.time())In SQL (MySQL):
-- Convert timestamp column to readable date
SELECT FROM_UNIXTIME(created_at) FROM users;
-- Convert date to timestamp
SELECT UNIX_TIMESTAMP('2026-06-02 00:00:00');The 2038 problem
32-bit signed integers can store values up to 2,147,483,647. Unix timestamps stored as 32-bit integers will overflow on January 19, 2038, at 03:14:07 UTC. After this point, a 32-bit timestamp would roll over to a negative number, causing systems to interpret the date as December 13, 1901.
This is the "Year 2038 problem" (Y2K38), analogous to the Y2K problem of 2000.
The solution: use 64-bit integers for timestamp storage. A signed 64-bit integer won't overflow for approximately 292 billion years. Most modern systems (Linux since kernel 5.1 on 32-bit ARM, databases with BIGINT timestamp columns, 64-bit applications) already use 64-bit time storage.
Where 2038 is still a concern: embedded systems, legacy 32-bit firmware, old databases using INT columns for timestamps, and some older programming languages that default to 32-bit integers.
Unix timestamps in APIs and databases
Unix timestamps are ubiquitous in technical systems:
- Database columns: Many databases store
created_atandupdated_atas Unix timestamps (integers) for efficient comparison and arithmetic, even when the display format is human-readable. - API responses: REST APIs frequently return timestamps as integers (e.g., Stripe, Twilio, GitHub, Slack). Always check whether the API returns seconds or milliseconds — documentation usually specifies.
- Log files: System logs, Apache/Nginx access logs, and application logs often include Unix timestamps for precise event ordering.
- JWT tokens: The
exp(expiration),iat(issued at), andnbf(not before) claims in JWT tokens are Unix timestamps in seconds.
Negative timestamps
Timestamps before January 1, 1970 are negative. The timestamp for January 1, 1900 would be approximately -2,208,988,800. Most systems handle negative timestamps correctly for modern use cases.
Related tools
- Free Unix Timestamp Converter — convert between Unix timestamps and human-readable dates in any timezone
- Free JSON Formatter — format API responses containing timestamps for easy reading
Written by Achraf A., founder of TheFreeAITools.