Unix timestamp

A Unix timestamp (or POSIX time, or seconds-since-epoch) is the number of seconds that have elapsed since 1970-01-01 00:00:00 UTC, ignoring leap seconds. As of 2026-05-16 the Unix timestamp is roughly 1,779,000,000.

Why this format dominates computing:

• It’s a single integer. No timezone, calendar, locale, or DST ambiguity baked in.
• Time arithmetic is trivial — subtract two timestamps to get a duration in seconds.
• Sortable as numbers. Database indexes and time-series queries don’t need fancy comparators.
• Compact in storage and over the wire.

Three flavours you’ll meet:

• Seconds. The original. 1700000000 = Nov 14 2023 22:13:20 UTC.
• Milliseconds. JavaScript’s Date.now() returns this. Multiply the seconds value by 1000.
• Microseconds / nanoseconds. High-resolution telemetry, distributed traces. Postgres’s timestamptz stores microseconds.

Two well-known problems:

• Year 2038 (Y2K38). A 32-bit signed integer of seconds overflows on 2038-01-19 at 03:14:07 UTC. Modern systems use 64-bit (good for ~292 billion years); legacy embedded systems may not.
• Leap seconds. UTC inserts occasional leap seconds to stay in sync with Earth’s rotation. Unix time ignores them — the timestamp at the leap second instant is ambiguous. Most production systems use a smear (Google, AWS) that spreads the leap second across hours.

Convert Unix timestamps to readable dates (and back) by feeding them into a date library. The conversion to a wall-clock time always requires a timezone choice — the same instant is “3pm in NYC” and “midnight in Tokyo” depending on which zone you display it in. See our time zone converter.

How operating systems are migrating off 32-bit time_t: Linux landed 64-bit time_t as the standard kernel ABI in 2020 (kernel 5.6+) and glibc 2.32 (2020) exposed it to userspace. NetBSD made the switch in 2012, OpenBSD in 2014. FreeBSD followed in 2024. The remaining lagging surfaces are embedded systems running pinned older kernels, certain on-chain protocols that hard-coded 32-bit timestamps in their wire format (Bitcoin’s block header includes a 32-bit Unix timestamp, problematic in ~2106 when unsigned overflow would occur), and legacy file formats (ZIP archives use 32-bit DOS timestamps with a 1980 epoch; tar uses 32-bit Unix timestamps). The hard work is finding and fixing these; the kernel side is largely done. Reference: POSIX.1-2017 §4.16 — Seconds Since the Epoch.

Worked example

Convert 1700000000 to a human-readable UTC date. Divide and modulo down from seconds: 1,700,000,000 / 86400 = 19,675.93 days since 1970-01-01. Day 19,675 is 2023-11-14 (calendar arithmetic). The fractional 0.93 of a day × 86,400 = 80,000 seconds = 22:13:20. So 1700000000 = 2023-11-14T22:13:20Z. Verify in JavaScript: new Date(1700000000 * 1000).toISOString() → "2023-11-14T22:13:20.000Z". To display in Tokyo (UTC+9): add 9 hours = 2023-11-15T07:13:20+09:00. The same instant, different wall-clock. The classic bug: storing new Date().getTime() (milliseconds) in a column the rest of the codebase treats as seconds — every timestamp ends up reading as the year 55,000+ when displayed.

When and why it matters

Whenever two systems exchange time data — frontend to backend, database to ETL pipeline, microservice to microservice — Unix timestamps are the only representation that doesn’t carry timezone, locale, calendar, or DST ambiguity. Store timestamps as Unix seconds or milliseconds in a 64-bit column, format to ISO-8601 with explicit timezone only at the edge for human display. The defensive habit: in every column or API field name that carries time, encode the unit (created_at_ms, expires_at_unix_seconds) so a code reviewer cannot mistake the order of magnitude. The Y2038 risk is small for new systems but real for any 32-bit timestamp in protocol wire formats and embedded sensors — audit those now while there’s 12 years of runway, not in 2037 when patches are urgent. Reference: RFC 3339 — Date and Time on the Internet.