Unix Timestamps Explained: The Developer's Guide to Epoch Time

BY TOOLS.FUN · MARCH 28, 2026 · 6 min read

Unix timestamps appear everywhere in software: API responses, database fields, log files, JWT expiry times, cache headers, and file metadata. They are the universal language of time in computing, yet many developers have a fuzzy understanding of what they actually represent. This guide covers everything you need to know about Unix time.

Related tools: use our JSON Formatter to inspect API responses containing timestamps, Base64 Decoder to decode JWT tokens with iat/exp claims, and Crontab Calculator to schedule jobs at specific times.

What is Unix Time?

Unix time (also called Unix timestamp, POSIX time, or epoch time) is a system for describing a point in time as a single integer: the number of seconds that have elapsed since the Unix epoch. The epoch is January 1, 1970, 00:00:00 UTC. A Unix timestamp of 1743120000, for example, represents a specific moment approximately 55 years after the epoch.

The beauty of Unix time is its simplicity: time comparisons are integer comparisons, duration calculations are subtractions, and the value is timezone-agnostic (always UTC). This makes it ideal for distributed systems where machines may be in different timezones.

Key point: Unix timestamps are always in UTC. There is no such thing as a "Unix timestamp in Pacific time". The timezone conversion is done only when displaying the timestamp to a human.

Why January 1, 1970?

The Unix operating system was being developed at Bell Labs in the late 1960s. The developers needed a reference date for the system clock. January 1, 1970 was chosen partly because it was recent (minimising the magnitude of timestamps for events in the near future) and partly because it was a convenient round number near the time of development. Earlier dates were considered but rejected — 1900, the epoch used by NTP, would have made early Unix timestamps too large for 32-bit arithmetic.

The choice is somewhat arbitrary, which is why other systems use different epochs: Windows FILETIME starts from January 1, 1601. Apple's Core Data uses January 1, 2001. GPS time starts from January 6, 1980.

Seconds vs Milliseconds vs Microseconds

The original Unix timestamp is in seconds. A typical timestamp looks like 1743120000 (10 digits). However, many modern systems and programming languages use milliseconds (13 digits: 1743120000000) or even microseconds (16 digits) or nanoseconds (19 digits) for higher resolution.

Seconds:      1743120000        (standard Unix time)
Milliseconds: 1743120000000     (JavaScript Date.now())
Microseconds: 1743120000000000  (Python time.time_ns() / 1000)
Nanoseconds:  1743120000000000000 (Go time.Now().UnixNano())

A common source of bugs is assuming a timestamp is in seconds when it's actually in milliseconds, or vice versa. A 13-digit number is milliseconds; a 10-digit number is seconds. If your code receives a timestamp of 1743120000000 and treats it as seconds, it will produce a date in the year 57,000+.

Key point: JavaScript's Date.now() and new Date().getTime() return milliseconds. Python's time.time() returns a float in seconds. When integrating JavaScript and Python systems, always verify which unit is being used.

Unix Time in Programming Languages

# Python — seconds (float)
import time
time.time()                    # 1743120000.123

# Python — integer milliseconds
import time
int(time.time() * 1000)        # 1743120000123

# JavaScript — milliseconds
Date.now()                     # 1743120000000

# JavaScript — seconds
Math.floor(Date.now() / 1000)  # 1743120000

# Go — seconds
time.Now().Unix()              # 1743120000

# Go — nanoseconds
time.Now().UnixNano()          # 1743120000000000000

# SQL (PostgreSQL) — current timestamp as epoch
SELECT EXTRACT(EPOCH FROM NOW())::BIGINT;

# Convert epoch to datetime (PostgreSQL)
SELECT TO_TIMESTAMP(1743120000);

Timezone Gotchas

Unix timestamps are absolute — they represent a specific moment in UTC. Timezone problems arise only when converting to or from human-readable representations. The most common bugs:

Storing a timestamp in a database without specifying UTC, then retrieving it in a different timezone — the stored value represents a different moment than intended.
Calling new Date(timestamp) in JavaScript and displaying it — the browser automatically converts to local time, which can show a different date than expected if the user is in a different timezone.
SQL DATETIME fields (MySQL) vs TIMESTAMP fields — DATETIME stores wall clock time without timezone conversion; TIMESTAMP stores UTC and converts on retrieval.

Key point: Always store timestamps in UTC. Convert to local time only at the presentation layer, as close to the user as possible. Use ISO 8601 format with explicit UTC offset (2026-03-28T12:00:00Z) when exchanging timestamps in APIs.

The Year 2038 Problem

On 32-bit systems, Unix time is stored as a signed 32-bit integer, which has a maximum value of 2,147,483,647. This maximum is reached at January 19, 2038, 03:14:07 UTC. After this moment, a 32-bit signed Unix timestamp overflows to a large negative number, representing dates in 1901.

Most modern 64-bit systems are unaffected — a 64-bit signed integer can represent times up to the year 292,277,026,596. However, embedded systems, legacy databases, file systems (ext3 uses 32-bit timestamps), and old applications that store timestamps in 32-bit fields may still be affected. The transition away from 32-bit Unix timestamps is ongoing.

Common Timestamp Formats in APIs

REST APIs use several timestamp formats. The most common:

Unix seconds — 1743120000 — compact, used by Stripe, GitHub webhooks, JWT exp claims
Unix milliseconds — 1743120000000 — used by Twitter, JavaScript-heavy APIs
ISO 8601 UTC — "2026-03-28T12:00:00Z" — human-readable, used by most REST APIs (GitHub, Slack, AWS)
RFC 2822 — "Sat, 28 Mar 2026 12:00:00 +0000" — used in HTTP headers (Date, Last-Modified) and email

Convert Timestamps Online

The Unix Timestamp Converter at Tools.Fun converts between Unix timestamps and human-readable dates in any timezone. Paste a 10-digit or 13-digit timestamp to see the date, or enter a date to get the corresponding epoch value — essential for debugging API responses and log files.

← Back