Unix Timestamps: The Complete Developer Guide

If you have ever looked at a database row and seen a column like 1745020800 where you expected a human-readable date, you were looking at a Unix timestamp. They are everywhere in software — API responses, log files, JWT tokens, file modification times, and nearly every database that stores time. Understanding them makes debugging time-related bugs dramatically easier.

What Is a Unix Timestamp?

A Unix timestamp is an integer that counts the number of seconds that have elapsed since the Unix epoch: January 1, 1970, at 00:00:00 UTC. The epoch is midnight, New Year's Day 1970, expressed in Coordinated Universal Time.

The timestamp increases by exactly 1 every second, regardless of what time zone you are in, what country you are in, or whether daylight saving time is in effect. This timezone-independence is the whole point — it makes Unix timestamps an unambiguous, globally consistent way to represent a specific moment in time.

The Unix Epoch

Why 1970? The Unix operating system was developed in the late 1960s at Bell Labs, and its developers needed a convenient reference point for time. January 1, 1970 was recent enough to avoid dealing with pre-computer history, and storing seconds since that date fit neatly into 32-bit integers on the hardware of the time. The choice was pragmatic, not profound.

A timestamp of 0 means exactly midnight UTC on January 1, 1970. A timestamp of 86400 (60 × 60 × 24) means exactly one day later: January 2, 1970, midnight UTC. Negative timestamps represent moments before the epoch — December 31, 1969, midnight UTC is -86400.

How to Get the Current Unix Timestamp

• •JavaScript: Math.floor(Date.now() / 1000) — Note: Date.now() returns milliseconds, so divide by 1000
• •Python: import time; int(time.time())
• •PHP: time()
• •Ruby: Time.now.to_i
• •Go: time.Now().Unix()
• •Rust: SystemTime::now().duration_since(UNIX_EPOCH).unwrap().as_secs()
• •Bash / terminal: date +%s (Linux/macOS)
• •SQL (PostgreSQL): EXTRACT(EPOCH FROM NOW())::BIGINT
• •SQL (MySQL / MariaDB): UNIX_TIMESTAMP()

Converting a Timestamp to a Human-Readable Date

• •JavaScript: new Date(timestamp * 1000).toISOString() — multiply by 1000 to convert to milliseconds
• •Python: from datetime import datetime, timezone; datetime.fromtimestamp(ts, tz=timezone.utc)
• •PHP: date("Y-m-d H:i:s", $timestamp)
• •Ruby: Time.at(timestamp).utc
• •Go: time.Unix(timestamp, 0).UTC()
• •SQL (PostgreSQL): TO_TIMESTAMP(1745020800)
• •SQL (MySQL): FROM_UNIXTIME(1745020800)

Millisecond Timestamps

JavaScript is the major exception to the "seconds" convention: Date.now() and the value stored by new Date() are in milliseconds, not seconds. This means JavaScript timestamps are about 1000× larger than Unix timestamps for the same moment. The current Unix timestamp is roughly 1.7 billion; the JavaScript millisecond timestamp is roughly 1.7 trillion.

This difference causes a classic bug: JavaScript developers store Date.now() in a database column that expects Unix seconds, then wonder why their dates show up as "year 55,000 something." Always be explicit about units — document whether a column stores seconds or milliseconds, and name it accordingly (created_at_ms vs created_at).

The Year 2038 Problem

On January 19, 2038, at 03:14:07 UTC, a Unix timestamp stored as a 32-bit signed integer will overflow. A 32-bit signed integer can hold values up to 2,147,483,647. At that exact second, the timestamp will hit that limit and roll over to −2,147,483,648 — which, when interpreted as a date, is December 13, 1901.

This is the "Year 2038 Problem" (sometimes called Y2K38). Most modern systems have already moved to 64-bit timestamps, which can represent dates hundreds of billions of years in the future. But older embedded systems, 32-bit operating systems, and legacy databases may still be affected. If you are building systems that store timestamps, always use 64-bit integers (BIGINT in SQL, int64 in Go, etc.).

Common Pitfalls

• •Confusing seconds and milliseconds (most common bug — causes dates ~50 years in the future or in 1970).
• •Storing local time as a Unix timestamp. A Unix timestamp is always UTC — if you add or subtract local time zone offsets before storing, you create ambiguous data.
• •Using 32-bit integers for timestamps. Use BIGINT or int64 always.
• •Assuming a timestamp has a time zone. It does not — it is a count of seconds since UTC epoch. Time zones are a display concern, applied when rendering.
• •Comparing timestamps from systems with clock drift. If two servers have unsynchronized clocks, their timestamps may differ by several seconds. Use NTP-synchronized clocks for any time-sensitive comparison.