Unix Timestamp Explained: Everything Developers Need to Know

Unix timestamps are one of those concepts every developer encounters but few take the time to fully understand. This guide covers everything — what a Unix timestamp is, why it exists, how to work with it in code, and the common pitfalls that trip people up.

What is a Unix timestamp?

A Unix timestamp (also called Epoch time, POSIX time, or Unix time) is the number of seconds that have elapsed since January 1, 1970 at 00:00:00 UTC. That specific moment is called the Unix epoch.

0          = January 1, 1970 00:00:00 UTC
1000000000 = September 9, 2001 01:46:40 UTC
1700000000 = November 14, 2023 22:13:20 UTC

The current Unix timestamp right now is approximately 1.7 billion — and increases by 1 every second.

Why do we use Unix timestamps?

• Timezone-independent: Unix timestamps are always in UTC. No ambiguity about timezones.
• Simple arithmetic: Comparing two timestamps is just subtraction. "Is event A before event B?" — compare the numbers.
• Universal: Every programming language and database understands Unix timestamps.
• Compact: A single integer stores a complete moment in time.

Seconds vs milliseconds — the most common confusion

Unix timestamps are traditionally in seconds (10 digits). But JavaScript uses milliseconds (13 digits).

1700000000    // seconds (Unix standard, 10 digits)
1700000000000 // milliseconds (JavaScript, 13 digits)

This causes real bugs. If you pass a millisecond timestamp to a function expecting seconds, you get a date far in the future (year 55000+). Always check which one your API or database expects.

Get the current Unix timestamp

// JavaScript (milliseconds)
Date.now()                          // 1700000000000

// JavaScript (seconds)
Math.floor(Date.now() / 1000)       // 1700000000

// Python
import time
int(time.time())                    // 1700000000

// PHP
time()                              // 1700000000

// Go
import "time"
time.Now().Unix()                   // 1700000000

// SQL (PostgreSQL)
EXTRACT(EPOCH FROM NOW())::INTEGER

// SQL (MySQL)
UNIX_TIMESTAMP()

Convert timestamp to date

// JavaScript
const ts = 1700000000;
const date = new Date(ts * 1000); // multiply by 1000 for ms
console.log(date.toISOString()); // "2023-11-14T22:13:20.000Z"
console.log(date.toLocaleString()); // local time string

// Python
from datetime import datetime, timezone
dt = datetime.fromtimestamp(1700000000, tz=timezone.utc)
print(dt.isoformat()) // "2023-11-14T22:13:20+00:00"

Convert date to timestamp

// JavaScript
const date = new Date('2023-11-14T22:13:20Z');
const ts = Math.floor(date.getTime() / 1000); // 1700000000

// Python
from datetime import datetime, timezone
dt = datetime(2023, 11, 14, 22, 13, 20, tzinfo=timezone.utc)
ts = int(dt.timestamp()) // 1700000000

The Year 2038 problem

On 32-bit systems, Unix timestamps are stored as a signed 32-bit integer. The maximum value is 2,147,483,647, which corresponds to January 19, 2038, 03:14:07 UTC. After that moment, 32-bit systems will overflow — a repeat of the Y2K problem.

Modern 64-bit systems don't have this problem — they can represent timestamps for hundreds of billions of years.