Unix Timestamp to Date Converter

What Is a Unix Timestamp?

A Unix timestamp is a single integer: the number of seconds (or milliseconds) that have elapsed since 00:00:00 UTC on 1 January 1970 — a moment called the Unix epoch. It was standardised in POSIX and has since become the universal way to represent time in computing. The timestamp 1717200000, for example, represents 2024-06-01T00:00:00Z. Because it is just a number, timestamps can be compared, sorted, stored, and transmitted without any parsing or locale logic.

Where You Will Encounter Unix Timestamps

Databases: PostgreSQL stores TIMESTAMPTZ internally as microseconds since epoch. MySQL's UNIX_TIMESTAMP() returns seconds. Redis EXPIREAT and TTL commands accept Unix timestamps directly. When you query a raw column, you often get back a number that needs converting before you can display it.

API responses: Stripe, GitHub, Twilio, Slack, and most REST APIs return created_at, updated_at, and expires_at fields as Unix timestamps. The Stripe Event object's created field is a Unix timestamp in seconds. If you process webhooks, you will need to convert this number to a Date object before formatting it for users.

JWT tokens: The exp (expiration) and iat (issued at) claims in JSON Web Tokens are Unix timestamps in seconds. Validating a JWT requires comparing exp to Math.floor(Date.now() / 1000) — the current Unix time in seconds.

Log files: Nginx, Apache, syslog, and many application loggers write timestamps as Unix integers in high-volume log formats to avoid string parsing overhead. When analysing logs with tools like jq or awk, you often need to convert these integers to readable dates.

Seconds vs Milliseconds — the Most Common Confusion

The original Unix standard uses seconds. JavaScript's Date.now() returns milliseconds. This causes constant bugs when integrating JavaScript frontends with backend systems.

A 10-digit number like 1717200000 is seconds. A 13-digit number like 1717200000000 is milliseconds. This converter auto-detects: values above 1 000 000 000 000 are treated as milliseconds. If you pass a seconds timestamp to new Date() without multiplying by 1000, you will get a date in 1970 — one of the most common JavaScript time bugs.

Timezone Handling

A Unix timestamp is always UTC. There is no timezone embedded in the number. When displaying a timestamp to a user, you must explicitly choose a timezone. new Date(ts * 1000).toLocaleString() uses the browser's local timezone. .toUTCString() forces UTC output. .toISOString() always returns UTC in ISO 8601 format.

Best practice: store all timestamps in UTC on the backend, convert to the user's local timezone only at the display layer. Never store local times in a database — DST transitions will corrupt your data.

Quick Reference — Converting in Code

// JavaScript
const d = new Date(1717200000 * 1000);
d.toUTCString();   // "Sat, 01 Jun 2024 00:00:00 GMT"
d.toISOString();   // "2024-06-01T00:00:00.000Z"
d.toLocaleString(); // locale-dependent

// Python
from datetime import datetime, timezone
dt = datetime.fromtimestamp(1717200000, tz=timezone.utc)
print(dt.isoformat())  # 2024-06-01T00:00:00+00:00

Frequently Asked Questions