What Is a Unix Timestamp? A Complete Developer Guide

The Number Behind Every Date on the Internet

Open any modern web application, inspect its API responses, or look at the created_at field in virtually any database — and you will find a number like 1746432000. This is a Unix timestamp, and it is one of the most fundamental concepts in software development. Yet a surprising number of developers use timestamps for years without fully understanding what they are, why they exist, or the subtle bugs they can cause.

This guide covers everything: the origin and logic of Unix timestamps, how to convert and manipulate them in major programming languages, the year-2038 problem, timezone pitfalls, and how to work with them efficiently without writing boilerplate every time.

---

What Is a Unix Timestamp?

A Unix timestamp is the number of seconds that have elapsed since January 1, 1970, at 00:00:00 UTC. This reference point is called the Unix epoch or POSIX epoch.

• 0 = January 1, 1970, 00:00:00 UTC
• 1000000000 = September 9, 2001, 01:46:40 UTC
• 1746432000 = May 5, 2026, 08:00:00 UTC
• -86400 = December 31, 1969, 00:00:00 UTC (negative timestamps represent dates before the epoch)

The key properties that make Unix timestamps powerful:

1. They are timezone-independent. The same timestamp represents the exact same moment in time anywhere on Earth. Converting to a local time happens at display time, not at storage time.
2. They are just integers. Comparing two timestamps is a simple number comparison. Adding 86400 to a timestamp gives you the same time the next day. Computing the difference between two events is subtraction.
3. They are compact. A 10-digit integer stores a date with second-level precision. No string parsing, no locale issues.

---

Why 1970? The History

The Unix operating system was being developed at Bell Labs in the late 1960s and early 1970s. The engineers needed a simple, universal way to represent time in the system. They chose an integer count from an arbitrary epoch — January 1, 1970 was close enough to "now" that the numbers would not be absurdly large for near-term use, and early enough that recent history could be represented.

The specific reason January 1, 1970 was chosen rather than, say, January 1, 1900 or January 1, 2000, is largely historical accident — it was a round, recent date that worked for the system being built. It was later standardized as part of the POSIX specification, which is why it remains universal across Linux, macOS, Windows, and virtually every other system.

---

Millisecond and Microsecond Timestamps

While the Unix timestamp standard counts seconds, many modern systems use milliseconds instead — especially JavaScript, which uses milliseconds throughout the Date API.

This is a common source of bugs. If your backend sends a timestamp in seconds and your frontend JavaScript interprets it as milliseconds, it will calculate a date in January 1970. If a timestamp in milliseconds is stored in a 32-bit integer field expecting seconds, overflow or truncation occurs.

Always document and verify which unit your timestamps use at API boundaries.

---

Getting the Current Timestamp

JavaScript

// Milliseconds (JavaScript standard)
const ms = Date.now();                    // 1746432000000

// Seconds
const seconds = Math.floor(Date.now() / 1000);  // 1746432000

// From a Date object
const ts = new Date().getTime();          // Milliseconds

Python

import time
import datetime

# Seconds (float, includes fractional seconds)
ts = time.time()                          # 1746432000.123456

# Integer seconds
ts_int = int(time.time())                 # 1746432000

# From datetime
dt = datetime.datetime.now(datetime.timezone.utc)
ts = dt.timestamp()

PHP

// Seconds
$ts = time();                             // 1746432000

// Milliseconds
$ts_ms = round(microtime(true) * 1000);

SQL (MySQL / PostgreSQL)

-- MySQL
SELECT UNIX_TIMESTAMP();                  -- Current timestamp in seconds
SELECT UNIX_TIMESTAMP(NOW());

-- PostgreSQL
SELECT EXTRACT(EPOCH FROM NOW())::BIGINT;

---

Converting a Timestamp to a Human-Readable Date

JavaScript

const ts = 1746432000;

// Method 1: Direct (milliseconds required)
const date = new Date(ts * 1000);
console.log(date.toISOString());          // "2026-05-05T08:00:00.000Z"
console.log(date.toLocaleDateString());   // Locale-specific format

// Method 2: Intl.DateTimeFormat (production-quality)
const formatter = new Intl.DateTimeFormat('en-IN', {
  timeZone: 'Asia/Kolkata',
  dateStyle: 'full',
  timeStyle: 'short'
});
console.log(formatter.format(date));      // "Monday, May 5, 2026 at 1:30 PM"

Python

import datetime

ts = 1746432000

# UTC datetime
dt_utc = datetime.datetime.fromtimestamp(ts, tz=datetime.timezone.utc)
print(dt_utc.isoformat())                 # "2026-05-05T08:00:00+00:00"

# Local timezone (IST example)
import zoneinfo
tz_ist = zoneinfo.ZoneInfo("Asia/Kolkata")
dt_ist = datetime.datetime.fromtimestamp(ts, tz=tz_ist)
print(dt_ist.strftime("%d %B %Y, %I:%M %p"))  # "05 May 2026, 01:30 PM"

Converting a Date to Timestamp

// JavaScript: specific date to timestamp
const date = new Date('2026-12-25T00:00:00Z');
const ts = Math.floor(date.getTime() / 1000);  // 1766620800

# Python
import datetime, zoneinfo

dt = datetime.datetime(2026, 12, 25, 0, 0, 0, tzinfo=datetime.timezone.utc)
ts = int(dt.timestamp())  # 1766620800

---

Timestamp Arithmetic: The Real Power

Because timestamps are integers, date calculations become arithmetic.

const now = Math.floor(Date.now() / 1000);

const oneHour   = 60 * 60;              // 3600 seconds
const oneDay    = 60 * 60 * 24;         // 86400 seconds
const oneWeek   = oneDay * 7;           // 604800 seconds
const thirtyDays = oneDay * 30;         // 2592000 seconds

// 24 hours from now
const tomorrow = now + oneDay;

// Was this event more than 7 days ago?
const eventTs = 1745827200;
const isOlderThanWeek = (now - eventTs) > oneWeek;  // Simple comparison

// How many days between two timestamps?
const ts1 = 1746432000;
const ts2 = 1749024000;
const daysBetween = Math.floor((ts2 - ts1) / oneDay);  // 30

This is why timestamps are the preferred storage format for dates in databases — sorting by date is just sorting by integer, range queries are integer comparisons, and arithmetic is trivial.

---

The Year-2038 Problem

This is a real issue for legacy systems. When Unix timestamps are stored in a signed 32-bit integer, the maximum value is 2,147,483,647 — which corresponds to January 19, 2038, at 03:14:07 UTC. After that second, a 32-bit signed timestamp overflows to a large negative number, representing a date in 1901.

Who is affected: Systems still using 32-bit int for timestamp storage — old C programs, certain older MySQL TIMESTAMP columns (which were 32-bit), embedded systems, and some legacy Unix kernels.

Who is not affected: Systems using 64-bit integers for timestamps. Modern 64-bit systems can represent timestamps until the year 292 billion — well beyond any practical concern. JavaScript's Date object uses a 64-bit float. Python's datetime handles dates until 9999. Modern 64-bit MySQL BIGINT columns have no issue.

What to do now: If you are designing a new system, store timestamps as BIGINT (64-bit) in databases, not INT. If you are maintaining legacy systems, the 2038 deadline is relevant — audit your timestamp storage types before 2038 if your systems are expected to run that long.

---

Timezone Pitfalls: The Most Common Bugs

The Golden Rule

Always store timestamps in UTC. Convert to local time only at display time.

This sounds obvious, but violations are everywhere. Common mistakes:

Mistake 1: Storing local time as a timestamp.

If a server in Mumbai creates a timestamp by taking local IST time (UTC+5:30) and treating it as UTC, every timestamp is off by 5.5 hours. Users in other timezones will see incorrect times.

Mistake 2: Not specifying timezone when parsing dates.

// DANGEROUS: Behavior depends on system timezone
new Date('2026-05-05')

// SAFE: Explicit UTC
new Date('2026-05-05T00:00:00Z')

The first example is parsed as local time in some browsers and UTC in others — this inconsistency caused countless bugs before developers understood it.

Mistake 3: Doing date arithmetic in local time.

If you add 86400 seconds to a timestamp, you get "exactly 24 hours later." But if a daylight saving time transition happens during that period, "the next calendar day at the same time" is either 23 or 25 hours later. For calendar-aware calculations (next Monday, one month from now), use a proper date library rather than raw arithmetic.

---

Converting Timestamps Without Code

If you need to quickly convert a Unix timestamp to a readable date — when debugging an API response, checking a log entry, or verifying a database record — writing code is overkill.

SimpleWebToolsBox offers a free Unix Timestamp Converter that works in your browser instantly. Paste any timestamp (seconds or milliseconds), select your timezone, and see the human-readable date and time. You can also convert in the reverse direction — pick a date and time and get the corresponding timestamp. No signup, no installation, runs entirely in your tab.

---

Quick Reference Table

---

Summary

• A Unix timestamp counts seconds since January 1, 1970, 00:00:00 UTC.
• They are timezone-independent, just integers, and ideal for storage, comparison, and arithmetic.
• JavaScript uses milliseconds by default; most other systems use seconds. Verify your units at API boundaries.
• Always store in UTC; convert to local time only when displaying to users.
• The 2038 problem affects systems using 32-bit integers — use 64-bit storage for all new systems.
• Arithmetic pitfalls exist around DST transitions; use date libraries for calendar-aware calculations.
• Convert timestamps instantly using the free Timestamp Converter on SimpleWebToolsBox.

---

Content Tracking Log