Unix Timestamps Explained (and How to Convert Them)

Every developer eventually encounters a mysterious 10-digit number in a log file, database column, or API response. That number is a Unix timestamp — and misunderstanding it (especially seconds vs milliseconds) is one of the most common sources of timezone and date bugs in web applications.

Convert any timestamp instantly with our Timestamp Converter, which runs entirely in your browser.

What is a Unix timestamp?

A Unix timestamp (also called epoch time) is the number of seconds that have elapsed since January 1, 1970, 00:00:00 UTC — a moment known as the Unix epoch. It is timezone-independent: the same integer means the same instant everywhere on Earth.

1735200000  →  2024-12-26T08:00:00.000Z (UTC)

Why do APIs and databases use timestamps?

• Compact: a single integer instead of a date string.
• Timezone-safe: no ambiguity about UTC vs local time in storage.
• Easy to compare: later times are simply larger numbers.
• Universal: supported by every programming language and database.

Seconds vs milliseconds — the #1 gotcha

Unix timestamps are traditionally in seconds(10 digits). JavaScript's Date.now() returns milliseconds (13 digits). Mixing them up produces dates in 1970 or year 50000+.

// JavaScript — milliseconds
Date.now()                    // 1735200000000

// Unix / Python / most APIs — seconds
Math.floor(Date.now() / 1000) // 1735200000

// If you pass seconds to new Date() without × 1000:
new Date(1735200000)          // 1970-01-21 — WRONG
new Date(1735200000 * 1000)   // 2024-12-26 — correct

ISO 8601 vs Unix timestamp

ISO 8601 strings like 2026-04-26T12:00:00.000Z are human-readable and include timezone information (the Z means UTC). JSON APIs often use ISO strings; databases and logs often use Unix integers. Both represent the same instant — they are just different formats.

Timezones and display

The timestamp itself is always UTC-based. When you convert it for display, your tool or library applies a timezone offset. A timestamp converted in New York and Tokyo shows different clock times but refers to the same moment. Always store UTC; convert to local time only for display.

Common mistakes

• Seconds vs milliseconds: the classic 1970 date bug.
• Treating local time as UTC: parsing 2026-04-26 12:00:00 without a timezone offset.
• Daylight saving time: storing local timestamps instead of UTC causes DST gaps and duplicates.
• 32-bit overflow: 32-bit systems had a Y2K-style problem in 2038; use 64-bit integers.

How to convert in code

JavaScript

const ts = 1735200000;
const date = new Date(ts * 1000);
console.log(date.toISOString()); // 2024-12-26T08:00:00.000Z

const backToSeconds = Math.floor(date.getTime() / 1000);

Python

from datetime import datetime, timezone
ts = 1735200000
dt = datetime.fromtimestamp(ts, tz=timezone.utc)
print(dt.isoformat())

Frequently asked questions

What is the Year 2038 problem?

32-bit signed integers overflow on January 19, 2038 when counting Unix seconds. Modern 64-bit systems are not affected, but legacy embedded systems may be.

Do Unix timestamps account for leap seconds?

POSIX Unix time does not count leap seconds. In practice this rarely affects web applications, but it matters for precise scientific or financial timing systems.

How do I get the current timestamp?

In JavaScript: Math.floor(Date.now() / 1000) for seconds. In Python: int(time.time()). Or use our converter's live clock section for an instant copy.