Unix Timestamp Converter
Epoch seconds to a date and time and back, in UTC only. Paste seconds or milliseconds and the result says which one it read, then gives you the ISO 8601 and RFC 2822 forms, the weekday, the day of the year, and whether the instant is past the 2038 limit.
One instant, in UTC
Switching directions carries the current answer across, so nothing has to be retyped.
Seconds or milliseconds — paste either and the result says which one it read. Negative values are dates before 1970.
Tue, 14 Nov 2023 22:13:20 +0000 — a Tuesday, day 318 of the year, and 2 years ago.
- Unix timestamp (seconds)
- 1700000000
- Milliseconds
- 1700000000000
- ISO 8601 (UTC)
- 2023-11-14T22:13:20Z
- RFC 2822
- Tue, 14 Nov 2023 22:13:20 +0000
- Day of the week
- Tuesday
- Day of the year
- 318
- Read your input as
- seconds
- Relative to now
- 2 years ago
- Fits a signed 32-bit time_t
- Yes
A count of seconds, a fixed starting point, and one deliberate lie
Unix time is a single integer: the number of seconds since 1970-01-01T00:00:00Z, an instant known as the epoch. It carries no time zone, no offset, and no daylight saving, which is exactly why it is the format software stores time in. Two systems on opposite sides of the world agree on the integer even when they disagree about what to call it.
t = (days since epoch × 86,400) + (h × 3,600) + (m × 60) + s- t
- The timestamp, in seconds since 1970-01-01T00:00:00Z
- 86,400
- Seconds in a day — a definition here, not a measurement
- h, m, s
- Hour, minute, and second of the UTC day
- Negative t
- Instants before 1970, which are legal and supported
The deliberate lie is the 86,400. Unix time defines a day to be exactly that many units, so it is not quite a count of elapsed seconds — see the leap-second section below. Everything else falls out of arithmetic: divide by 86,400 for the day number, take the remainder for the time of day, and read the day number against the Gregorian calendar.
Taking 1,700,000,000 apart by hand
Divide by the length of a day: 1,700,000,000 ÷ 86,400 = 19,675 whole days, with 80,000 seconds left over. Nineteen thousand six hundred and seventy-five days after 1 January 1970 is 14 November 2023.
Now unpack the remainder. 80,000 ÷ 3,600 = 22 hours, leaving 800 seconds. 800 ÷ 60 = 13 minutes, leaving 20 seconds. So the time of day is 22:13:20, and the whole timestamp is 2023-11-14T22:13:20Z — a Tuesday, the 318th day of the year. That is the default this page loads with, so the arithmetic above and the converter above it can be checked against each other.
One more, for the unit question. Paste 1700000000123 and the answer is the same instant with 123 milliseconds on the end — thirteen digits is a millisecond timestamp, and the converter says so rather than placing you in the year 55,853.
A dated fault, still being manufactured into hardware
Unix time was defined against a signed 32-bit integer. The largest value that holds is 2,147,483,647, and that second is 2038-01-19T03:14:07Z. One second later the counter overflows to −2,147,483,648, which any conforming reader will render as 1901-12-13T20:45:52 UTC. Not an error, not a crash — a confident, wrong date, one hundred and thirty-seven years early.
It is tempting to file this alongside Y2K as something that was handled. It has been, where the storage is easy to widen: 64-bit time_t is standard on current servers, phones, and Linux distributions, and a 64-bit counter does not run out for roughly 292 billion years. What has not been handled is everything where the 32 bits are structural rather than incidental — embedded controllers with a decade or more of service life still shipping today, industrial and building-automation equipment, filesystem metadata formats with fixed-width fields, and network protocols whose wire format cannot be widened without breaking every implementation at once.
Switching to an unsigned 32-bit counter is a common patch, and it buys time rather than fixing anything: it gives up dates before 1970 and runs out on 2106-02-07T06:28:15Z. This converter flags any instant outside the signed 32-bit window, which makes it a quick way to check whether a date you are about to store is on the far side of the line.
Why this is not quite a count of elapsed seconds
The Earth’s rotation is slightly irregular and slightly slow relative to atomic time, so UTC is occasionally corrected by inserting a leap second — a real, extra second labelled 23:59:60 — announced by the IERS in Bulletin C about six months ahead. Twenty-seven have been inserted since 1972; the most recent was at the end of 2016.
Unix time ignores them. Its day is 86,400 units by definition, so during a leap second the counter repeats the previous second’s value instead of advancing. Two consequences follow. First, the difference between two Unix timestamps understates the elapsed SI seconds between those instants — by up to twenty-seven seconds across the whole span since 1972. Second, there is no timestamp that names 23:59:60, which is why this converter refuses second 60 rather than quietly rounding it into the next minute.
The problem is on its way out. In November 2022 the 27th General Conference on Weights and Measures resolved to stop inserting leap seconds by 2035, allowing the difference between UTC and atomic time to grow instead. Existing timestamps are unaffected: the seconds already skipped stay skipped.
What this converter assumes
- Everything is UTC. No time zone is read from your device and none is applied, in either direction. If you enter a local wall clock time it will be treated as UTC and the answer will be off by your offset.
- The unit is guessed by magnitude. At or above 100,000,000,000 the input is read as milliseconds. A millisecond timestamp from before March 1973 falls below that line and will be misread as seconds — a narrow window, named here rather than engineered around.
- Leap seconds are not counted, following the POSIX definition. A Unix day is exactly 86,400 units whatever the Earth did that year.
- The supported span is the year 1000 through the year 9999, which is the range a four-digit ISO 8601 year covers. Because of the unit guess, the seconds route itself tops out in the year 5138.
- “Relative to now” uses your device’s clock, rounded down to the minute, and does not tick while you read. It is the only value on this page your device contributes; the conversion itself is the same for everyone.
- Sub-second precision is preserved but not invented. A millisecond input keeps its fraction in the ISO string; a whole-second input does not grow a
.000it never had, and the RFC 2822 form never carries one because that format has no field for it.
Unix timestamp FAQ
What time zone is a Unix timestamp in?
None — and that is the point of the format. A Unix timestamp counts seconds from 1970-01-01T00:00:00Z, so at any given instant it is the same integer everywhere on Earth. Turning one into a wall-clock time is where a zone enters, and this converter deliberately does not: everything it prints is UTC. Applying a local zone correctly means knowing that zone's offset on that date, and offsets change by legislation, sometimes with only weeks of notice. A converter carrying a stale copy of those rules would be confidently wrong rather than obviously silent.
Is my timestamp in seconds or milliseconds?
Count the digits. A present-day timestamp in seconds is ten digits and one in milliseconds is thirteen — 1700000000 against 1700000000000. This converter decides by magnitude: at or above 100,000,000,000 it reads the value as milliseconds, because that is the year 5138 in seconds but only March 1973 in milliseconds. It then tells you which unit it used, so the guess is visible rather than silent. The rule of thumb for the source: C's time() and most Unix tooling return seconds, while JavaScript's Date.now() and most JVM and .NET APIs return milliseconds.
What is the year 2038 problem?
Unix time was originally stored in a signed 32-bit integer, which cannot count past 2,147,483,647. That instant is 2038-01-19T03:14:07Z; one second later the counter overflows and reads −2,147,483,648, which is 1901-12-13T20:45:52Z. It is not a solved problem. 64-bit time_t is standard on servers, phones and current Linux distributions, but 32-bit fields are still shipped in embedded controllers, industrial equipment, filesystem metadata formats, and network protocols whose wire format cannot be widened without breaking every implementation. An unsigned 32-bit counter buys time rather than fixing it — it runs out on 2106-02-07T06:28:15Z.
Does Unix time count leap seconds?
No, and this is the detail that surprises people who assume it is a count of elapsed seconds. Unix time defines every day as exactly 86,400 units, so when UTC inserts a leap second as 23:59:60 the Unix counter repeats the previous second's value rather than counting a new one. Twenty-seven leap seconds have been inserted since 1972, so the difference between two Unix timestamps understates the elapsed SI seconds between those instants by up to that much. The trade is deliberate: it is what makes “divide by 86,400” a calendar day with no table to consult.
Can a Unix timestamp be negative?
Yes. Negative values are instants before 1970 — −86400 is 1969-12-31T00:00:00Z. They are legal, this converter accepts them, and plenty of software handles them badly, which is a good reason to test with one. Note that the second containing a negative fractional value is the one below it, not above: −1,500 milliseconds falls inside second −2, because seconds are numbered from their start.
Why does this stop at the year 9999?
The bound comes from ISO 8601, not from arithmetic. The standard writes years as exactly four digits; anything outside that requires expanded representation — a mandatory sign and an agreed digit count, as in +010000-01-01 — which almost nothing parses and no log file emits. A converter that accepted the year 12,345 would hand back a string its own readers could not feed anywhere. One consequence of guessing the unit: a value in seconds at or above 100,000,000,000 is read as milliseconds instead, so the seconds route tops out in the year 5138.
Sources and review notes
- The Open Group Base Specifications Issue 7, “Seconds Since the Epoch” — the POSIX definition, including the 86,400-second day and the exclusion of leap seconds
- RFC 3339 — the internet profile of ISO 8601 that the
Z-suffixed date-time strings on this page follow - IERS Bulletin C — the standing announcement of whether a leap second will be inserted at the end of the current half-year
- BIPM, CGPM Resolution 4 (2022) — the decision to stop inserting leap seconds by 2035
The arithmetic on this page cannot go stale: the epoch is fixed, the Gregorian calendar is fixed, and the 2038 limit is a property of 32 bits. The one figure with a future is the leap-second count, which stands at twenty-seven and, under the 2022 resolution, is unlikely to move again.