Unix Timestamps: Everything You Need to Know

5 min read · Updated September 2026

A Unix timestamp is the number of seconds since January 1, 1970 00:00:00 UTC (the "Unix epoch"). It's the universal language of time in computing — every database, API, and logging system uses it.

Seconds vs Milliseconds

The #1 Source of Bugs

JavaScript uses milliseconds (13 digits). Most APIs use seconds (10 digits). Always check which one you're dealing with. A 10-digit timestamp in JavaScript gives a date in 1970.

Seconds (Unix time) — 10 digits: 1718236800 (June 13, 2024)
Milliseconds (JavaScript) — 13 digits: 1718236800000

Common Conversions

// JavaScript: Get current timestamp

Math.floor(Date.now() / 1000) // seconds

Date.now() // milliseconds

// JavaScript: Convert timestamp to date

new Date(timestamp * 1000) // if seconds

new Date(timestamp) // if milliseconds

// Python: Get current timestamp

import time; int(time.time()) // seconds

ISO 8601 Format

The human-readable standard for timestamps:

2026-06-13T12:00:00Z — UTC time (Z = Zulu)
2026-06-13T08:00:00-04:00 — With timezone offset (EDT)
2026-06-13T12:00:00.123Z — With milliseconds

Worked Example: Debugging a Wrong Date from an API

A developer fetches an order and displays its date with new Date(1718236800). The screen shows January 20, 1970 — 54 years too early. The debugging steps:

Count the digits: 1718236800 has 10 digits, so the API returns seconds
JavaScript expects milliseconds, so multiply by 1000: new Date(1718236800 * 1000)
The result is now correctly June 13, 2024 00:00:00 UTC
Display it in the user's timezone with toLocaleString() rather than assuming everyone is in UTC

Input value	Digits	Correct call	Result
1718236800	10	new Date(t * 1000)	June 13, 2024
1718236800000	13	new Date(t)	June 13, 2024
1718236800000000	16	new Date(t / 1000)	June 13, 2024 (microseconds)

The same digit-count check works in reverse: when sending a timestamp to an API, confirm the unit it expects, or your events will silently land decades off — you can verify any value instantly with the Unix Timestamp Converter.

Common Mistakes

Mixing seconds and milliseconds in one system — one service stores seconds, another multiplies by 1000 "to be safe," and every date ends up 1000 years off. Pick one unit and enforce it everywhere.
Parsing dates with the wrong timezone — new Date("2026-06-13") is parsed as UTC midnight, while new Date(2026, 5, 13) is local midnight. Know which behavior your code relies on.
Storing local time instead of UTC — when daylight saving shifts, every stored wall-clock time becomes ambiguous or wrong. Store UTC and convert only at display time.
Doing timestamp math on strings — comparing ISO strings works only when the formats are identical. Convert to numbers before any arithmetic or comparison.
Forgetting negative timestamps — dates before 1970 are negative. Code that checks if (ts > 0) silently rejects every historical date.

Frequently Asked Questions

When will Unix timestamps run out?

Not soon for anyone using 64-bit integers: they cover roughly 292 billion years. The classic 2038 problem applies only to 32-bit signed integers, which overflow in January 2038 — still a real concern for embedded systems and legacy hardware.

Do leap seconds break timestamps?

Unix time ignores leap seconds; every day is treated as exactly 86,400 seconds. Real UTC inserts occasional leap seconds, so Unix time can drift from true time by about a second. For almost all applications this is irrelevant.

Should I store ISO 8601 strings or integers in my database?

Both are common. Integers are compact, sortable, and timezone-proof; ISO 8601 strings are human-readable in a query browser. Use your database's native timestamp type when available — it gives you both properties at once.

How do I convert a timestamp in Excel or Google Sheets?

Divide the seconds value by 86,400 (seconds per day) and add 25569, the spreadsheet serial number of the Unix epoch, then format the cell as a date. The same formula works in both: =A1/86400 + 25569.