Unix Timestamps: Seconds, Milliseconds & Conversion

Language

Code

JavaScript

Date.now() // ms

Python

import time; time.time() # s

Java

System.currentTimeMillis() // ms

time.Now().Unix() // s

PHP

time(); // s

MySQL

SELECT UNIX_TIMESTAMP(); -- s

Key Takeaways

Definition: seconds elapsed since the Unix epoch (1970-01-01 UTC) — a timezone-free instant

Digit check: 10 digits = seconds; 13 = milliseconds (×1,000); 16 = microseconds

Conversion: ts → date is UTC math; displaying local time is a separate, later step

2038 problem: signed 32-bit seconds overflow 2038-01-19 — legacy systems still lurk

Core answer: A Unix timestamp counts seconds since 1970-01-01 00:00:00 UTC (the epoch): 1,735,689,600 = 2025-01-01 00:00:00 UTC = 2025-01-01 08:00:00 Beijing (UTC+8). Millisecond versions multiply by 1,000 (JS's Date.now()). The 32-bit signed limit overflows on 2038-01-19 — the Y2K38 problem. Timestamps have NO time zone; zones only appear when formatting for humans.

Seconds vs milliseconds (the #1 confusion)

Value	Unit	Meaning
1735689600	seconds	2025-01-01 00:00 UTC
1735689600000	milliseconds	same instant
1735689600000000	microseconds	databases, logs
1735689600000000000	nanoseconds	Go's time.Now().UnixNano()

Quick check: a current seconds timestamp is ~1.7 billion (10 digits); milliseconds ~1.7 trillion (13 digits). Passing seconds where ms are expected lands you in January 1970 + a few weeks — the classic bug.

Converting by hand (sanity checks)

1 day = 86,400 s; 1 year ≈ 31,556,952 s.
Beijing time = UTC + 8 h = timestamp + 28,800 s when displaying.
2025-01-01 = 1735689600 → +86400/day: 1735776000 = Jan 2 00:00 UTC.

Worked examples

Example 1 — Log analysis. Server log shows 1735682400: subtract 1735689600 (midnight) → −7,200 s = 2 h before midnight UTC = 2024-12-31 22:00 UTC = 2025-01-01 06:00 Beijing.

Example 2 — Token expiry. JWT exp: 1735689600 means "invalid AT/AFTER this instant" — compare with the current seconds (not ms!) or tokens live 1,000× longer than intended.

Example 3 — Cache TTL. "Cache for 1 h" = now + 3600. Storing Date.now() + 3600 in JS gives ms + seconds = garbage; use Date.now() + 3_600_000.

Example 4 — The 2038 audit. Embedded systems using 32-bit time_t overflow 2038-01-19 03:14:07 UTC; banks' 30-year mortgages and infrastructure firmware already audit this.

Common mistakes and myths

"Timestamps are in UTC" — they're zone-less; UTC is just how we describe the epoch. The same instant is one number worldwide.
ms/s unit bugs — the single most common timestamp error; name variables createdAtMs vs createdAtSec.
Storing local wall time — "2025-03-09 02:30" doesn't exist in US DST spring-forward and exists twice in fall; store instants (timestamps), render locally.
Assuming monotonicity — NTP sync can move system clock backward; for measuring durations use monotonic clocks (performance.now(), Instant in Java), never wall time.
Database defaults drift — MySQL TIMESTAMP (range to 2038) vs DATETIME (to 9999, no TZ conversion): choose deliberately, migrate before 2038.

Frequently Asked Questions

What is a Unix timestamp?

The number of seconds since 1970-01-01 00:00:00 UTC (the "epoch"), ignoring leap seconds. 0 = the epoch itself; 1735689600 = 2025-01-01 00:00:00 UTC; 2,000,000,000 lands 2033-05-18. It is one integer describing one instant — no zones, no formats, no ambiguity — which is why databases, logs and APIs speak it natively.

Is my timestamp in seconds or milliseconds?

Count digits at current dates: 10 digits ≈ 1.7 billion = seconds (Unix standard); 13 digits = milliseconds (JavaScript Date.now(), Java); 16 = microseconds (some Python/C contexts); 19 = nanoseconds (Go time.UnixNano). Misreading the unit shifts dates by ~1,000×: seconds interpreted as ms lands in 1970 + a few weeks; ms read as seconds lands in year ~56,000. The digit count is the instant diagnostic.

How do I convert timestamps to dates?

The math: days = ts ÷ 86,400, then civil-date algorithm — nobody hand-computes it; use libraries: JS new Date(1735689600 * 1000), Python datetime.fromtimestamp(ts, tz=timezone.utc), SQL to_timestamp(ts). Quick sanity anchors: 86,400 s/day, ~31.56M s/year, 1.7B ≈ 2023-2025 era. For display, then apply the target timezone — conversion and localization are two separate steps.

Why are timestamps timezone-independent?

The timestamp counts seconds from a fixed UTC instant — 1735689600 means the same moment in Beijing, London and New York; only the DISPLAY differs (08:00 Beijing = 00:00 London = 19:00 New York previous day). Best practice: store and transmit timestamps (or UTC ISO strings), convert to local time at the presentation layer only. Bugs breed when local strings travel between systems.

What is the Year 2038 problem?

Signed 32-bit integers max at 2,147,483,647 = 2038-01-19 03:14:07 UTC — one second later, systems storing seconds in int32 wrap to 1901. Embedded systems, old databases (MySQL TIMESTAMP type!), and legacy binaries are the risk zone. Mitigations: 64-bit time fields (modern defaults), TIMESTAMP → DATETIME migrations. Y2K38 is smaller than Y2K but real for infrastructure that outlives its authors.

What mistakes happen with timestamps?

(1) s/ms unit confusion (digit count!); (2) displaying UTC values as if local (off by the offset — 8h for Beijing); (3) Date.now() ÷ 1000 rounding direction in JS; (4) assuming monotonicity — NTP corrections and leap smears can step clocks; (5) storing local-naive datetime strings as "timestamps"; (6) comparing ISO strings with mixed offsets lexicographically; (7) int32 columns in new schemas (use BIGINT / 64-bit); (8) forgetting negative timestamps exist (pre-1970 dates are negative — some systems reject them).