What Is a Unix Timestamp? A Friendly Guide to Time for Developers

If you have ever stared at a string of digits like 1710892800 and wondered whether it was a secret code, a database ID, or a bug report from the year 3000 — congratulations. You have met a Unix timestamp.

This guide explains what timestamps are, why they show up everywhere in software, how seconds and milliseconds differ, and how to convert them into human-readable dates. When you want to try things yourself, open our free Timestamp Converter — it runs entirely in your browser and supports both seconds and milliseconds.

The short answer

A Unix timestamp (also called Unix time, POSIX time, or Epoch time) is the number of seconds that have passed since:

January 1, 1970, 00:00:00 UTC

That moment is called the Unix Epoch. Everything after it counts up. Everything before it (negative timestamps) counts backward into the 1960s and earlier — useful for historians and people who still argue about when Star Trek first aired.

So when you see 0, you are looking at midnight UTC on New Year's Day 1970. When you see 1000000000, you are looking at September 9, 2001 — a date so iconic that programmers around the world celebrated "Unix billennium" parties.

Why not just store "March 20, 2026"?

Human dates are messy. Computers prefer numbers.

Consider these headaches that timestamps quietly avoid:

• Timezones. "3 PM" in New York is not "3 PM" in Tokyo. A single integer in UTC is unambiguous.
• Formats. Is 03/04/05 March 4, 2005 — or April 3, 2005 — or something else entirely? Timestamps do not care about locale.
• Sorting and math. Want every event between two moments? Compare two integers. Want "30 days ago"? Subtract 30 * 24 * 60 * 60. Done.
• Databases and APIs. JSON, logs, cookies, JWTs, file systems, message queues — almost every system that records "when" eventually speaks Epoch.

In short: timestamps are the Esperanto of time. Not pretty, but everyone can negotiate in it.

Seconds vs milliseconds (the classic footgun)

Not all timestamps are created equal.

| Style | Typical length | Example | Used by | | --- | --- | --- | --- | | Seconds | ~10 digits | 1710892800 | Unix, many APIs, older systems | | Milliseconds | ~13 digits | 1710892800000 | JavaScript Date.now(), Java, many modern APIs |

Mix them up and your date jumps to the year 56000 — or collapses into 1970. It is the most common timestamp bug in JavaScript interviews and production outages alike.

Rule of thumb:

• Around 10 digits → treat as seconds
• Around 13 digits → treat as milliseconds

Our Timestamp Converter has an Auto mode that guesses from digit length, plus explicit Seconds and Milliseconds modes when you want full control. You can also convert a calendar date back into both formats.

A quick mental model

Think of the Epoch as a stopwatch that started ticking in 1970 and never paused for coffee.

• 60 → one minute after the Epoch
• 3600 → one hour
• 86400 → one day
• 31536000 → roughly one non-leap year

Leap years and leap seconds make the "roughly" part interesting — more on that below — but for everyday app work, these multiples are good enough to reason with.

Where you will meet timestamps in the wild

Once you notice them, they are everywhere:

1. Log files — "error at 1710892800" is friendlier to machines than prose.
2. Authentication tokens — JWT exp and iat claims are usually Unix seconds.
3. Caches and cookies — expiry times are often Epoch-based.
4. Analytics and event streams — ordering millions of clicks needs a total order.
5. Mobile and web apps — scheduling reminders, chat messages, upload times.
6. Blockchain and distributed systems — consensus protocols love a shared clock reference (even if clocks themselves disagree).

If your stack talks to the outside world, it almost certainly already speaks timestamp.

Timezones: the plot twist

A timestamp itself is timezone-agnostic. It is a point on the UTC timeline.

What changes is how you display it:

• Same timestamp → 2024-03-20 00:00:00 UTC
• Same timestamp → 2024-03-19 20:00:00 in New York (EDT)
• Same timestamp → 2024-03-20 09:00:00 in Tokyo (JST)

That is why APIs usually store and exchange UTC timestamps, then let each client render local time. When something looks "off by eight hours," it is usually a timezone conversion bug — not a broken clock.

Try this: paste a timestamp into the Timestamp Converter and compare the UTC, Local, and ISO 8601 rows. Same instant, three faces.

Leap seconds and the Year 2038 problem (bonus lore)

Leap seconds

Earth's rotation is not a perfect metronome. Occasionally, standards bodies insert a leap second so civil time stays aligned with astronomy. Unix time traditionally ignores leap seconds in a simplified model (every day is treated as 86400 seconds). For most applications this is fine. For high-frequency trading, GPS, or scientific measurement, you may need more specialized time scales.

The Year 2038 problem

On systems that store Unix time as a signed 32-bit integer, the maximum value is 2,147,483,647 — which lands on January 19, 2038. After that, the counter overflows (similar in spirit to Y2K). Modern 64-bit systems and languages are already past this limitation, but embedded devices and old C code can still surprise you.

Knowing this trivia will not fix a broken Date parse — but it will make you sound dangerously competent in meetings.

ISO 8601: the human-readable cousin

Timestamps are great for machines. Humans prefer something like:

2026-03-20T12:00:00.000Z

That is ISO 8601 — sortable as text, timezone-aware with the Z (UTC) or an offset like +08:00, and widely supported. Many systems store Epoch internally and expose ISO strings at the edges.

A good converter should speak both dialects. Ours shows ISO alongside Unix seconds and milliseconds so you can copy whichever format your API expects.

Practical recipes

"What time is this log line?"

1. Copy the number from the log.
2. Open the Timestamp Converter.
3. Choose Seconds or Milliseconds (or Auto).
4. Hit Convert and read Local / UTC / Relative ("3 hours ago").

"I need an expiry 7 days from now"

1. Use Date → Timestamp with today's date, or start from Use Seconds / Use Milliseconds.
2. Add 7 * 86400 seconds (or the millisecond equivalent).
3. Or pick the future date in the date picker and convert.

"Is this value seconds or ms?"

Count the digits. When in doubt, convert both ways and see which result looks like a plausible year. If one result says year 57000, you found the wrong unit.

Common mistakes (and how to dodge them)

• Treating local midnight as UTC. Always know which zone your input assumes.
• Multiplying twice. seconds * 1000 * 1000 is not "more precise" — it is wrong.
• Parsing with new Date(string) carelessly. Browser locale rules vary; prefer ISO or explicit Epoch.
• Forgetting that JS Date uses milliseconds. new Date(1710892800) is 1970-ish; you probably wanted 1710892800000.
• Comparing strings that look like dates. Sort Epoch integers or ISO strings — not 03/04/05.

Try it yourself

Reading about time is useful. Playing with real numbers is better.

→ Open the Timestamp Converter
Convert Unix seconds or milliseconds to dates, or dates back to timestamps. Supports Auto detection, UTC/local display, ISO 8601, and one-click copy. Everything runs locally in your browser — nothing is uploaded.

Whether you are debugging a JWT, cleaning a log dump, or settling a timezone argument in Slack, a reliable converter turns those mysterious digits back into something you can actually schedule lunch around.