Unix Timestamp (Epoch Time) & POSIX Time

A Unix Timestamp (also referred to as Epoch Time, POSIX Time, or UNIX Time) is an integer or floating-point numerical representation of time, measured as the total number of elapsed seconds since the Unix Epoch—defined as 00:00:00 UTC on Thursday, January 1, 1970 (excluding leap seconds).

Because Unix timestamps are timezone-agnostic and monotonic, they are universally employed in database engines, REST/gRPC APIs, message queues, JSON Web Tokens (JWT), and system logs to represent discrete instants in time without ambiguity.

Convert, format, and inspect Unix timestamps across all timezones with our client-side Unix Timestamp Converter tool and calculate multi-city team schedules with the Timezone Converter.

---

Technical Specifications & Precision Scales

While original POSIX specifications defined timestamps in whole seconds, modern distributed architectures operate across varying resolutions:

Precision Level	Decimal Digits	Typical Integer Representation	Common Systems & Runtimes
Seconds ($s$)	10 digits	1715629200	POSIX time_t, Python time.time(), Redis TTL, JWT exp/iat, MySQL UNIX_TIMESTAMP()
Milliseconds ($ms$)	13 digits	1715629200000	JavaScript Date.now(), Java System.currentTimeMillis(), MongoDB ISODate
Microseconds ($\mu s$)	16 digits	1715629200000000	Python datetime.now().timestamp(), PostgreSQL timestamptz, Apache Cassandra
Nanoseconds ($ns$)	19 digits	1715629200000000000	Go time.Now().UnixNano(), Rust SystemTime, Linux kernel clock, InfluxDB

---

The Year 2038 Problem (Y2038)

The Year 2038 Problem (also called the Unix Millennium Bug) arises on systems storing Unix timestamps in 32-bit signed integers (int32):

• Maximum 32-bit Signed Integer: $2^{31} - 1 = 2,147,483,647$
• Exact Saturation Instant: Tuesday, January 19, 2038 at 03:14:07 UTC
• Overflow Consequence: Adding one second causes integer overflow into negative values ($-2,147,483,648$), wrapping clocks back to Friday, December 13, 1901 at 20:45:52 UTC.

Modern 64-bit architectures (int64) expand this limit to $2^{63} - 1 \approx 9.22 \times 10^{18}$ seconds, which guarantees precision for approximately 292 billion years into the future.

---

Leap Seconds and POSIX Time Semantics

International Atomic Time (TAI) counts continuous physical seconds. Because the Earth's rotational speed fluctuates, the International Earth Rotation and Reference Systems Service (IERS) periodically inserts leap seconds into UTC to keep solar time aligned.

However, standard POSIX Unix time does not count leap seconds. A standard POSIX day is rigidly defined as having exactly 86,400 seconds ($24 \times 60 \times 60$). When a leap second occurs (such as 23:59:60 UTC), POSIX systems handle it via leap-smearing (gradually slowing the clock over several hours) or by repeating the timestamp 23:59:59 to maintain arithmetic compatibility ($t_2 - t_1 = 86400$).

---

Parsing & Formatting Code Snippets

Node.js / TypeScript

// Current timestamp in seconds and milliseconds
const epochMs = Date.now();
const epochSec = Math.floor(epochMs / 1000);

// Converting Unix epoch to ISO 8601 UTC string
const isoString = new Date(epochMs).toISOString();
// Output: "2024-05-13T19:40:00.000Z"

// Converting ISO date string back to Unix seconds
const seconds = Math.floor(new Date("2024-05-13T19:40:00.000Z").getTime() / 1000);

Python 3

import time
from datetime import datetime, timezone

# Get current Unix timestamp (float with microsecond precision)
now_epoch = time.time()
epoch_seconds = int(now_epoch)

# Convert epoch to timezone-aware UTC datetime
dt = datetime.fromtimestamp(epoch_seconds, tz=timezone.utc)
iso_formatted = dt.isoformat()
# Output: "2024-05-13T19:40:00+00:00"

Go

package main

import (
	"fmt"
	"time"
)

func main() {
	// Current Unix timestamp
	sec := time.Now().Unix()
	nano := time.Now().UnixNano()

	// Convert epoch seconds to UTC time.Time
	t := time.Unix(sec, 0).UTC()
	fmt.Println(t.Format(time.RFC3339))
}

Rust

use std::time::{SystemTime, UNIX_EPOCH};

fn main() {
    let now = SystemTime::now();
    let duration = now.duration_since(UNIX_EPOCH).expect("Time went backwards");
    let seconds = duration.as_secs();
    let millis = duration.as_millis();
    
    println!("Epoch seconds: {}, millis: {}", seconds, millis);
}

SQL (PostgreSQL & MySQL)

-- PostgreSQL: Convert epoch to TIMESTAMPTZ and back
SELECT TO_TIMESTAMP(1715629200) AT TIME ZONE 'UTC';
SELECT EXTRACT(EPOCH FROM NOW())::BIGINT;

-- MySQL: Convert epoch to DATETIME and back
SELECT FROM_UNIXTIME(1715629200);
SELECT UNIX_TIMESTAMP(NOW());

---

Best Practices for Timestamp Engineering

1. Persist Exclusively in UTC: Always store timestamps in databases as raw integer epoch values or timezone-aware columns (TIMESTAMPTZ in PostgreSQL). Never store ambiguous local time strings without timezone offsets.
2. Normalize Digit Length on Ingestion: APIs accepting external timestamps must validate digit lengths (10 digits for seconds, 13 for milliseconds) before passing into date constructors to avoid date calculation errors in year 53,000+.
3. Use RFC 3339 for JSON Payloads: While integer epochs are compact for binary protocols, human-readable ISO 8601 / RFC 3339 strings with an explicit Z suffix (e.g. 2024-05-13T19:40:00.000Z) eliminate client-side parsing ambiguity.
4. Leverage Time-Sorted Identifiers: Modern distributed architectures use hybrid time-ordered identifiers like ULID and UUID v7, which embed 48-bit Unix epoch millisecond prefixes directly into primary keys for high B-Tree database indexing performance.