Unix Timestamp Explained: Convert, Read & Use Timestamps (2026)

Most timestamp bugs are timezone bugs.

That is the pattern across virtually every timestamp-related production incident. The timestamp itself is fine. The conversion is fine. Someone just assumed the wrong timezone at some point in the pipeline -- the database stores in local time, the API returns UTC, the frontend displays local, and somewhere in that chain the date appears wrong by 5, 7, or 11 hours depending on where the user is sitting.

Unix timestamps exist precisely to solve this problem. A Unix timestamp is a single integer -- seconds elapsed since midnight January 1, 1970 UTC. It has no timezone. It means the same thing in every country on every server. Human-readable dates are for people. Timestamps are for systems.

This guide covers what Unix timestamps are, how to read and convert them, why the seconds-vs-milliseconds confusion causes so many bugs, and how to avoid the common mistakes that make timestamp problems hard to debug.

Unix timestamp quick answer

The table below defines the core terminology used throughout this guide.

Unix timestamp quick reference

The current timestamp when reading this guide is somewhere around 1,750,000,000. To get the exact current timestamp: Math.floor(Date.now() / 1000) in JavaScript, int(time.time()) in Python, date +%s in a Unix terminal.

What is a Unix timestamp?

Direct answer: A Unix timestamp is a single integer representing the number of seconds that have passed since midnight January 1, 1970 UTC. It is a globally consistent way to represent any point in time without timezone ambiguity.

The integer representation is the key advantage. When you store the integer 1700000000, it means exactly one thing: 1.7 billion seconds after the Unix epoch. A developer in New York and a developer in Tokyo looking at 1700000000 are looking at the same moment in time. Neither has to know the other's timezone. Neither has to worry about daylight saving time. The timestamp just says “this many seconds after a known starting point.”

A Unix timestamp is only useful when everyone agrees on the clock -- and for Unix timestamps, everyone does. The clock is UTC, the unit is seconds, and the starting point is January 1, 1970 midnight. These conventions are supported by every operating system, every programming language, every database engine, and every API.

What Unix timestamps do not carry: date, month, year, hour, minute, second, or timezone. All of that is derived by converting the integer. The integer itself is just a count.

What is Unix epoch?

Direct answer: The Unix epoch is the starting point from which Unix timestamps are counted: January 1, 1970 at exactly 00:00:00 Coordinated Universal Time (UTC). Every Unix timestamp is the number of seconds before or after this moment.

How Unix timestamps work

Direct answer: A Unix timestamp counts seconds continuously upward from the epoch. Every second that passes increases the timestamp by 1. The count never resets and is independent of timezones, daylight saving, calendars, or geographic location.

Converting to human time (JavaScript, Python, Terminal):

// JavaScript
new Date(1700000000 * 1000)           // multiply by 1000 for ms
new Date(1700000000 * 1000).toISOString()  // "2023-11-14T22:13:20.000Z"

# Python
from datetime import datetime, timezone
datetime.fromtimestamp(1700000000, tz=timezone.utc)
# datetime(2023, 11, 14, 22, 13, 20, tzinfo=timezone.utc)

# Terminal
date -d @1700000000        # Linux
date -r 1700000000         # macOS

Unix timestamp vs human dates

Human-readable dates are for people. Timestamps are for systems. The right architecture stores timestamps as integers (or UTC datetime fields) in the database and converts to human-readable format only when displaying to users.

Unix timestamp: seconds vs milliseconds

Direct answer: Unix timestamps are traditionally in seconds (10 digits, e.g., 1700000000). JavaScript's Date.now() returns milliseconds (13 digits, e.g., 1700000000000). Confusing the two is one of the most common timestamp bugs.

How to identify and convert between units:

// Check which unit your timestamp is in
const ts = 1700000000;
const isSeconds = ts.toString().length === 10;
const isMilliseconds = ts.toString().length === 13;

// Convert between units
const fromSeconds = ts * 1000;         // seconds to milliseconds
const fromMilliseconds = ts / 1000;    // milliseconds to seconds

// Get current timestamp
Date.now()                             // milliseconds (13 digits)
Math.floor(Date.now() / 1000)          // seconds (10 digits)

import time
time.time()               # float: 1700000000.123 (seconds)
int(time.time())          # int: 1700000000 (seconds)
int(time.time() * 1000)   # milliseconds

Real example 1: convert timestamp to date

Input: 1700000000

// JavaScript
new Date(1700000000 * 1000).toISOString()
// "2023-11-14T22:13:20.000Z"  (November 14, 2023, 10:13:20 PM UTC)

# Python
from datetime import datetime, timezone
datetime.fromtimestamp(1700000000, tz=timezone.utc).isoformat()
# "2023-11-14T22:13:20+00:00"

# Terminal (Linux)
date -d @1700000000 --utc
# Tue Nov 14 22:13:20 UTC 2023

Reverse conversion (date to timestamp):

// JavaScript
Math.floor(new Date('2023-11-14T22:13:20Z').getTime() / 1000)
// 1700000000

# Python
int(datetime(2023, 11, 14, 22, 13, 20, tzinfo=timezone.utc).timestamp())
# 1700000000

The Z at the end of the ISO date string is critical -- it specifies UTC. Without it, the conversion uses the local timezone and produces a different timestamp.

Real example 2: JWT token expiration

Direct answer: JWT tokens use Unix timestamps (in seconds) for three time-related claims: exp (when the token expires), iat (when it was issued), and nbf (when it first becomes valid).

A decoded JWT payload:

{
  "sub": "user_123",
  "iss": "auth.myapp.com",
  "iat": 1749996400,
  "exp": 1750000000,
  "nbf": 1749996400
}

The expiration check:

const payload = decodeJWT(token);
const now = Math.floor(Date.now() / 1000);  // current time in seconds
const isExpired = payload.exp < now;

The full JWT guide is at JWT Tokens Explained.

Real example 3: API response timestamps

Direct answer: APIs return timestamps in various formats. Understanding which format to expect (and how to parse each) prevents display bugs.

A typical API response with timestamps:

{
  "id": "order_abc123",
  "status": "completed",
  "created_at": 1700000000,
  "updated_at": "2023-11-14T22:13:20Z",
  "processed_at": "2023-11-14T22:13:20.456+00:00",
  "expires_at": null
}

UTC vs local time

Direct answer: UTC (Coordinated Universal Time) is the global time standard that Unix timestamps use. Local time is UTC adjusted by a timezone offset. Store UTC. Convert for display.

Common timestamp mistakes

Why timestamp bugs happen

Direct answer: Most timestamp bugs arise from one of four sources: unit mismatch (seconds vs milliseconds), timezone assumptions (UTC vs local), DST transitions, or inconsistency between where timestamps are generated and where they are consumed.

When a date is wrong, first check whether it is off by a round number of hours (timezone issue), off by exactly 1000x (unit issue), or ambiguous around a DST boundary. These three checks resolve most timestamp bugs.

Unix timestamp converter example

Converting a timestamp manually requires knowing the calendar arithmetic for handling leap years, month lengths, and so on. In practice, nobody does this by hand -- but knowing the conversion exists in every language is useful.

For debugging -- checking what exp: 1750000000 in a JWT actually means, verifying a date stored in a database, or confirming that a cron schedule will fire at the right UTC time -- a timestamp converter is the right tool. Many developers validate date calculations using the Vortenza Unix Timestamp Converter before deploying production systems. Paste a timestamp, see the UTC date and time, convert to any timezone, and verify the calculation.

Unix timestamp vs ISO 8601

Database timestamp best practices

Direct answer: Store timestamps in UTC. Use native datetime types rather than integer columns when possible. Convert to the user's local timezone only at the display layer.

PostgreSQL:

-- Use TIMESTAMPTZ (timestamp with time zone) -- stores in UTC internally
CREATE TABLE events (
    id SERIAL PRIMARY KEY,
    name VARCHAR(255),
    created_at TIMESTAMPTZ DEFAULT NOW(),
    scheduled_at TIMESTAMPTZ NOT NULL
);

-- Insert with explicit UTC
INSERT INTO events (name, scheduled_at)
VALUES ('Meeting', '2023-11-14 22:13:20+00');

-- Query and convert to display timezone at query time
SELECT name, scheduled_at AT TIME ZONE 'America/New_York' AS local_time
FROM events;

TIMESTAMPTZ stores in UTC and converts automatically. TIMESTAMP (without timezone) is stored as-is and can cause confusion when the database server's timezone changes.

MySQL:

CREATE TABLE events (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(255),
    created_at DATETIME DEFAULT UTC_TIMESTAMP(),
    scheduled_at DATETIME NOT NULL
);

-- Insert UTC explicitly
INSERT INTO events (name, scheduled_at)
VALUES ('Meeting', UTC_TIMESTAMP());

MySQL's TIMESTAMP type auto-converts between UTC and server timezone on insert/select. DATETIME stores exactly what you put in; use UTC_TIMESTAMP() to ensure UTC values.

MongoDB:

// MongoDB insert (JavaScript driver)
await db.events.insertOne({
  name: 'Meeting',
  created_at: new Date(),  // UTC by default in JavaScript Date
  scheduled_at: new Date('2023-11-14T22:13:20Z')
});

One-minute timestamp audit

Quick answers

Optimized for ChatGPT, Gemini, Perplexity, Claude, and Google AI Overviews.

Q: What is a Unix timestamp?

A: A Unix timestamp is an integer representing the number of seconds elapsed since January 1, 1970 at 00:00:00 UTC (the Unix epoch). It is timezone-independent and universally supported across all programming languages, operating systems, and databases. The current timestamp is approximately 1,750,000,000. It increases by 1 every second.

Q: What is Unix epoch?

A: The Unix epoch is the reference point for Unix timestamps: January 1, 1970 at exactly 00:00:00 Coordinated Universal Time (UTC). Every Unix timestamp is the number of seconds before or after this moment. The date was chosen by Unix developers in the late 1960s as a practical starting point.

Q: How do I convert a Unix timestamp to a date?

A: In JavaScript: new Date(1700000000 * 1000).toISOString() (multiply by 1000 for milliseconds). In Python: datetime.fromtimestamp(1700000000, tz=timezone.utc). In a Unix terminal: date -d @1700000000 --utc (Linux) or date -r 1700000000 (macOS). All convert 1700000000 to November 14, 2023 22:13:20 UTC.

Q: What is the difference between Unix timestamp seconds and milliseconds?

A: Unix timestamps in seconds are 10 digits (e.g., 1700000000). JavaScript's Date.now() returns milliseconds (13 digits, e.g., 1700000000000). The difference is a factor of 1000. Passing milliseconds where seconds are expected produces dates thousands of years in the future. Count digits to identify which you have.

Q: Why does my timestamp show January 1, 1970?

A: You are almost certainly passing seconds where milliseconds are expected. The value is being interpreted as milliseconds close to the epoch. Multiply the value by 1000 and pass it to new Date() in JavaScript, or ensure you are using the correct unit throughout.

Q: What is UTC and why do timestamps use it?

A: UTC (Coordinated Universal Time) is the global time standard from which all other timezones are defined. Unix timestamps use UTC because it has no daylight saving time, no political adjustments, and a stable relationship with international atomic time. A timestamp in UTC means the same thing everywhere in the world.

Q: What is the Year 2038 problem?

A: The Year 2038 problem is a potential overflow issue for systems storing Unix timestamps as 32-bit signed integers. The maximum 32-bit signed integer (2,147,483,647) corresponds to January 19, 2038 at 03:14:07 UTC. After that second, a 32-bit counter overflows to a large negative number. Systems using 64-bit integers are not affected.

Q: How do I get the current Unix timestamp?

A: In JavaScript: Math.floor(Date.now() / 1000) (seconds) or Date.now() (milliseconds). In Python: int(time.time()) (seconds). In PHP: time() (seconds). In Go: time.Now().Unix() (seconds). In a Unix terminal: date +%s. All return the current number of seconds since January 1, 1970 UTC.

Q: What are JWT timestamp claims?

A: JWT tokens use three Unix timestamp claims (in seconds): exp (expiration -- the token is invalid after this time), iat (issued at -- when the token was created), and nbf (not before -- the token is invalid before this time). Always compare them against Math.floor(Date.now() / 1000) in JavaScript, not against Date.now().

Q: What is ISO 8601 and how does it relate to Unix timestamps?

A: ISO 8601 is a human-readable date format: 2023-11-14T22:13:20Z. The Z suffix indicates UTC. Both ISO 8601 and Unix timestamps represent moments in time formatted differently. Unix timestamps are better for storage and comparison; ISO 8601 strings are better for APIs and human debugging. The same moment: 1700000000 and 2023-11-14T22:13:20Z.

Q: How do I store timestamps in a database?

A: Use the database's native datetime type with timezone support: TIMESTAMPTZ in PostgreSQL, DATETIME with explicit UTC insertion in MySQL, or MongoDB's native Date type. Store all timestamps in UTC. Never store in local time. Convert to the user's timezone only at the display layer in the application.

Q: Why does my timestamp look wrong in a different timezone?

A: The timestamp is correct (it always represents a UTC moment), but the display conversion is using the wrong timezone. Check: is the conversion using the user's timezone or the server's timezone? Are you using UTC-explicit functions, or functions that default to local time? Is DST being handled correctly for the target timezone?

Q: Can Unix timestamps represent dates before 1970?

A: Yes, as negative integers. January 1, 1960 is approximately -315,619,200. Most modern systems and languages support negative Unix timestamps for historical dates. However, some older systems and certain libraries handle only non-negative timestamps.

Q: What timezone does a Unix timestamp represent?

A: A Unix timestamp is always UTC. It has no timezone of its own -- it is simply a count of seconds since the UTC epoch. When you convert a Unix timestamp to a human date, you choose a timezone for display. The timestamp itself does not change; only the display format reflects the timezone.

Q: How do I add or subtract time from a Unix timestamp?

A: Add or subtract seconds directly. One hour from now: currentTimestamp + 3600. One day from now: currentTimestamp + 86400. One week: currentTimestamp + 604800. For adding calendar months or years (which have variable lengths), use a date library rather than fixed-second arithmetic to handle month length and leap year differences correctly.

For full explanations, see the Frequently asked questions section below or the FAQ accordion.

Frequently asked questions

Full explanations with context. For concise answers, see Quick answers above.

Tools used in this guide

Related guides