What is a Unix Timestamp? A Developer's Complete Guide

What is a Unix Timestamp?

A Unix timestamp is the total number of seconds that have elapsed since January 1, 1970, at 00:00:00 UTC. This reference moment is called the Unix epoch. It is a single, unambiguous integer that represents any point in time, past or future.

For example:

• 0 = January 1, 1970, 00:00:00 UTC
• 86400 = January 2, 1970, 00:00:00 UTC (one day = 86,400 seconds)
• 1000000000 = September 9, 2001, 01:46:40 UTC
• 1700000000 = November 14, 2023, 22:13:20 UTC

Unix timestamps are timezone-agnostic. The number itself is always in UTC. Displaying a timestamp in a human-readable local time is a separate operation that applies a timezone offset on top of the UTC value.

Why January 1, 1970?

The Unix epoch was not chosen for any cosmic reason — it was a practical decision made by the engineers developing the original Unix operating system at Bell Labs in the early 1970s. They needed a fixed reference point that was recent enough to be computationally convenient but predated the start of the system.

The original Unix systems used 32-bit signed integers with a unit of 1/60th of a second. As the system evolved, the unit changed to seconds, and the epoch was set to January 1, 1970, because it was a convenient round date near the time of development. The Wikipedia article on Unix time covers the historical context in detail.

Notably, negative Unix timestamps are valid and represent dates before January 1, 1970. The timestamp -86400 is December 31, 1969, 00:00:00 UTC.

Seconds vs Milliseconds

The original Unix timestamp specification uses seconds. However, many programming languages and APIs — particularly in the JavaScript ecosystem — work in milliseconds because modern applications need sub-second precision for animations, performance measurement, and real-time systems.

System / Language	Default Unit	Current Value (approx. 2024)
Unix/Linux (C time_t)	Seconds	~1,700,000,000
JavaScript Date.now()	Milliseconds	~1,700,000,000,000
Python time.time()	Seconds (float)	~1,700,000,000.xxx
Java System.currentTimeMillis()	Milliseconds	~1,700,000,000,000
Go time.Now().Unix()	Seconds	~1,700,000,000
PostgreSQL EXTRACT(epoch)	Seconds (float)	~1,700,000,000.xxx
MongoDB BSON Date	Milliseconds	~1,700,000,000,000

The Year 2038 Problem

The Year 2038 problem — sometimes called Y2K38 — is one of the more significant known technical deadlines in computing. It stems from the use of 32-bit signed integers to store Unix timestamps.

A 32-bit signed integer can hold values from −2,147,483,648 to 2,147,483,647. The maximum positive value, 2,147,483,647, corresponds to January 19, 2038, at 03:14:07 UTC. One second later, the counter overflows and wraps around to −2,147,483,648 — which the system interprets as December 13, 1901, 20:45:52 UTC. Systems that store timestamps as 32-bit signed integers will misinterpret dates after this threshold.

Who Is Affected?

Modern 64-bit systems are not affected because they use 64-bit integers for timestamps, which can store dates billions of years into the future. The risk lies in:

• Legacy embedded systems (industrial controllers, medical devices, automotive systems) with 32-bit processors running decades-old firmware
• Old database schemas storing timestamps in 32-bit integer columns (MySQL's TIMESTAMP type was affected until version 8.0.28)
• Any C/C++ code compiled for 32-bit targets using the standard time_t type

Major operating systems and programming languages have already transitioned to 64-bit time_t on 64-bit platforms. The primary concern going forward is legacy embedded hardware that cannot be easily updated.

Timezone Gotchas

Timezone handling is the source of more bugs in datetime code than almost any other cause. Understanding the relationship between Unix timestamps and timezones is critical.

Key Principles

• Unix timestamps are always UTC. The number 1700000000 means the same moment everywhere on Earth. It is the representation that changes per timezone, not the timestamp value itself.
• Timezone offsets are display-time concerns. Store timestamps in UTC. Apply timezone conversions only when displaying to users.
• UTC offsets are not fixed. Daylight saving time (DST) changes a timezone's offset by one hour on specific dates. If you add 3,600 seconds (1 hour) to a timestamp, you do not always advance by one "clock hour" in a DST-observing timezone — the clock may show no change or a two-hour jump across a DST boundary.
• Leap seconds exist. Unix time does not account for leap seconds — it assumes every day has exactly 86,400 seconds. In practice this means Unix time can drift by a few seconds relative to actual atomic time, though this rarely matters for application development.

The RFC 3339 specification defines the date-time format that includes explicit timezone offset information, reducing timezone ambiguity in data exchange.

Unix Timestamps in JavaScript

JavaScript's Date object works with milliseconds internally. The MDN Date documentation covers every method in detail. Here are the most common timestamp operations:

Getting the Current Timestamp

// Milliseconds since epoch (most common)
const ms = Date.now();              // e.g. 1700000000000

// Seconds since epoch (Unix standard)
const sec = Math.floor(Date.now() / 1000);  // e.g. 1700000000

// Alternative: using Date object
const ms2 = new Date().getTime();
const ms3 = +new Date();            // coercion shorthand

Converting a Timestamp to a Date String

const ts = 1700000000;              // seconds

// JavaScript Date constructor takes milliseconds
const date = new Date(ts * 1000);

console.log(date.toISOString());    // "2023-11-14T22:13:20.000Z"
console.log(date.toUTCString());    // "Tue, 14 Nov 2023 22:13:20 GMT"
console.log(date.toLocaleDateString('en-US')); // "11/14/2023"

Converting a Date to a Timestamp

// From a date string
const ts = Math.floor(new Date('2024-01-01T00:00:00Z').getTime() / 1000);
// ts = 1704067200

// From individual components (month is 0-indexed!)
const ts2 = Math.floor(new Date(2024, 0, 1, 0, 0, 0).getTime() / 1000);

Common Timestamp Operations

Adding Time to a Timestamp

Because timestamps are just integers, arithmetic is straightforward. Use these constants:

• 1 minute = 60 seconds
• 1 hour = 3,600 seconds
• 1 day = 86,400 seconds
• 1 week = 604,800 seconds
• 1 year (approximate) = 31,536,000 seconds

const now = Math.floor(Date.now() / 1000);
const oneDayLater = now + 86400;
const oneWeekAgo  = now - 604800;

Comparing Two Timestamps

Comparing timestamps is simple integer comparison:

const ts1 = 1700000000;
const ts2 = 1700086400;

if (ts2 > ts1) {
  const diffSeconds = ts2 - ts1;      // 86400 — one day apart
}

Checking if a Timestamp Is Expired

function isExpired(expiryTimestamp) {
  return Math.floor(Date.now() / 1000) > expiryTimestamp;
}

ISO 8601 vs Unix Timestamps

ISO 8601 is a human-readable date format defined by the International Organization for Standardization. An ISO 8601 datetime looks like 2024-11-01T09:00:00Z (the trailing Z means UTC). Unix timestamps are the machine-readable equivalent — a raw integer.

Property	Unix Timestamp	ISO 8601
Format	Integer (1700000000)	String (2023-11-14T22:13:20Z)
Human readable	No	Yes
Timezone info	Implicit (always UTC)	Explicit offset (+05:30, Z)
Arithmetic	Simple integer math	Requires parsing
Sortable as string	Yes (10-digit seconds)	Yes (lexicographic)
Storage size	4–8 bytes (integer)	20–30 bytes (string)
Best for	Database storage, computation	APIs, logs, display

For API design, ISO 8601 is generally preferred because it is self-documenting and includes explicit timezone information. For database storage and arithmetic, Unix timestamps are more efficient. Many systems use both: store as Unix timestamp, expose as ISO 8601 in the API response.

To convert between Unix timestamps and human-readable dates quickly, use the ToolMasta timestamp converter. You can also explore related converter tools like the unit converter for other measurement needs.