About the Unix Timestamp Converter
This Unix timestamp converter works in both directions: paste an epoch value to get a readable date, or enter a date to get the seconds and milliseconds since the epoch. It detects automatically whether a numeric input is in seconds or milliseconds, and returns the result as ISO 8601, a UTC string and your browser's local time all at once, which is usually enough to settle whether a timezone bug or a genuine data problem is at fault. Dates can be given in ISO 8601 or plain YYYY-MM-DD form.
How to use the Unix Timestamp Converter
- 1
Choose the Direction — Timestamp to date, or Date to timestamp.
- 2
Enter the Value: a numeric timestamp in seconds or milliseconds, or a date such as 2023-11-14T22:13:20Z.
- 3
Read the Converted panel for seconds, milliseconds, ISO 8601, UTC and local time.
- 4
Copy the All formats block when you need every representation at once.
What people use it for
Reading a timestamp out of a log file
Server logs, JWT expiry claims and database columns all store epoch integers, and translating one into a readable time is the first step in almost any incident investigation.
Debugging a timezone discrepancy
Seeing the UTC and local renderings of the same instant side by side quickly reveals whether an offset is being applied twice or not at all.
Setting an expiry value in an API call
Token expiry, cache headers and scheduled jobs frequently want an absolute epoch value, so converting a target date gives you the number to send.
Checking a JWT before it is rejected
The exp and iat claims in a token are epoch seconds, and converting them tells you whether a token has genuinely expired or a clock is out of sync.
What the epoch is and what it deliberately ignores
A Unix timestamp counts the seconds elapsed since 00:00:00 UTC on 1 January 1970, a moment chosen as a convenient round date shortly before Unix development began. Its great virtue is that it is a single integer with no timezone, no locale and no formatting, which makes it unambiguous to store, trivial to compare and cheap to sort. What it silently ignores is leap seconds. UTC has had 27 of them inserted since 1972 to keep clocks aligned with the Earth's slightly irregular rotation, but POSIX defines a day as exactly 86,400 seconds, so a Unix timestamp simply pretends the leap second never happened — most implementations repeat or stretch a second so the count stays smooth. This means the value is not a true count of elapsed SI seconds since 1970, and it is off by those 27 seconds. For virtually every application that does not matter; for high-precision timing, astronomy or financial timestamping regimes such as MiFID II it does, which is why those domains use TAI or a leap-smearing scheme with an explicit contract.
The year 2038 problem
Systems that store a timestamp in a signed 32-bit integer can represent values up to 2,147,483,647, which is reached at 03:14:07 UTC on 19 January 2038. One second later the integer overflows and wraps to its most negative value, which is interpreted as 13 December 1901. This is the same class of bug as Y2K, and in some respects harder, because the affected values are buried in C structures, on-disk file formats, embedded firmware and network protocols rather than in obvious display strings. It is not a future problem in every case: any system doing 20-year arithmetic — mortgages, pension projections, long-dated certificates — has already been encountering it, and several have. Modern 64-bit platforms use a 64-bit time_t, which pushes the limit roughly 292 billion years out, and JavaScript sidesteps the issue by storing milliseconds in a double, giving safe integers well past year 275760. The remaining exposure is in embedded devices, older filesystems and any protocol that pinned a 32-bit field.
Seconds against milliseconds
The single most common bug when working with epoch values is a factor-of-1000 error, because different platforms disagree on the unit. Unix system calls, most Linux tooling, JWT claims and Postgres extract(epoch) all work in seconds, while JavaScript's Date.getTime(), Java's System.currentTimeMillis() and most JSON APIs written in those languages work in milliseconds. Some systems go further into microseconds or nanoseconds. Passing seconds where milliseconds are expected gives a date in January 1970; passing milliseconds where seconds are expected gives a date far in the future. This tool disambiguates by magnitude: any value whose absolute size is 100,000,000,000 or more is treated as milliseconds, anything smaller as seconds. That threshold is safe because a second-based timestamp will not reach it until the year 5138, and a millisecond-based one passed it back in 1973.
Tips
- The ISO 8601 output always ends in Z, meaning UTC; the local line is the same instant in your browser's timezone.
- Store instants as UTC timestamps and convert to local time only at the point of display.
- Negative timestamps are valid and represent dates before 1970, which is a useful check when a date renders as 1969 or 1901.