Timestamp Converter

About Unix timestamps

A Unix timestamp counts seconds (or milliseconds) since January 1, 1970 UTC — the "epoch." It's a single number that unambiguously represents a moment in time, independent of timezone or calendar formatting, which is why most systems store and exchange dates this way internally.

Unix time famously ignores leap seconds — every day is defined as exactly 86,400 seconds, so the rare leap seconds that keep clocks aligned with Earth's rotation are simply absorbed rather than counted, which is why Unix time is sometimes called "nearly linear" rather than truly linear. A more practical limit: the traditional 32-bit signed representation of Unix time overflows on January 19, 2038 — the so-called Year 2038 problem — though most systems today store timestamps as 64-bit values, which pushes the same overflow roughly 292 billion years out.

Where you'll run into it

• Reading a created_at or expires_at field from an API response or database row
• Debugging why a JWT's exp or iat claim doesn't match what you expected
• Converting a log timestamp to your local time while investigating an incident
• Checking whether a cache, token, or session has actually expired

Frequently asked

How do I know if a timestamp is in seconds or milliseconds?
Seconds-based timestamps for recent dates are 10 digits long; millisecond-based ones are 13. This tool detects which one you pasted automatically.

Why does my timestamp look "wrong" by a few hours?
A Unix timestamp itself has no timezone — it's an exact instant. What changes is how it's displayed: the UTC and Local rows here show the same instant, just formatted for two different timezones.

Does this handle dates before 1970?
Yes — negative timestamps represent moments before the epoch, and this tool parses and displays them the same way.

What is the Year 2038 problem?
A traditional 32-bit signed Unix timestamp can only count up to 2,147,483,647 seconds after the epoch, which arrives at 03:14:07 UTC on January 19, 2038 — one second later, it overflows and wraps to a negative number, which typically gets read as a date in 1901. Systems still using 32-bit timestamps (some embedded and older 32-bit software) are affected; most modern 64-bit systems already store timestamps in 64 bits, which defers the same overflow far beyond any practical timeframe.