Unix Timestamp Converter

Date and time → timestamp

How to use it

1. Paste the number and press Convert. You do not need to know whether it is seconds or milliseconds. If you do know, set the unit and the tool stops inferring anything.
2. Read the unit line before the date. It says whether the unit was your choice or its own decision, and what the other reading would have been. That line is the whole point of this page: a timestamp converter that shows only a date cannot be checked.
3. Compare the zones. UTC comes first because it is what logs, databases and APIs are written in. Your own zone comes next because it is what you actually picture. The selected zone is there for the case that matters most — a log from a server in another country, or a deadline quoted in someone else's time.

Seconds or milliseconds: how the unit is decided

This is the failure that makes the whole category untrustworthy. 1757000000 is 4 September 2025 if it is seconds and 21 January 1970 if it is milliseconds. Both are dates. Both are formatted correctly. Nothing about the number itself says which one the sender meant, so a tool that picks silently is guessing — and when it guesses wrong, the output still looks like a date, which is why the mistake survives review.

This tool has one stated rule, and it uses a window rather than a vibe:

The rule in full, as implemented:

• Both readings are computed first. One as seconds, one as milliseconds.
• If only one of them lands between 1900-01-01 and 2100-12-31, that is the reading shown. The window is this tool's stated assumption about what a real timestamp looks like, not a fact about your data.
• If both land inside that window — or neither does — the tool says so. When both are real dates it falls back to the digit rule above and shows you the other date beside it, so you can spot the error yourself. When neither is a real date it refuses to produce a single answer and shows both readings instead.

Anything else would be inventing certainty. And there is a way to stop the inference entirely: choose Seconds or Milliseconds in the unit selector and the tool reports exactly what you asked for, including the case where that reading is absurd.

UTC, your zone, and the zone you pick

A Unix timestamp is not a date. It is a signed count of seconds from 1970-01-01 00:00:00 UTC, and it becomes a calendar date only when you say which zone to read it in. That is why the same number is three different wall times on this page, and why the differences are not errors: 1757000000 seconds is 15:33 in UTC, 23:33 the same evening in Tokyo and 08:33 the same morning in Los Angeles.

Three consequences worth knowing:

• A date can shift by one day. Between roughly 16:00 and 24:00 UTC, a zone east of UTC+8 is already on the next calendar day. If you are reading a server log from another region, the date in your head and the date in the log are not the same date — and the log is the one that gets archived.
• Offset is not the same thing as zone. +08:00 is a fixed offset that never changes; Asia/Shanghai is a zone whose offset is a rule that can be redefined by a government. When you store or send a time with an offset, you keep the instant; when you store a zone name, you also keep the intent.
• The zone list and every offset come from your browser. The page asks Intl for them, which means it uses the same time zone database as the rest of your system. Nothing is bundled here and no table is maintained on this site, because a copied table of offsets is wrong the moment a country changes its rules — and it would be wrong silently.

Four output formats are shown for each result, because they answer different questions: ISO 8601 in UTC is what you paste into a database or a JSON field; ISO 8601 with the offset keeps the local wall time and removes the ambiguity at the same time; RFC 2822 is the format older protocols still expect; and the readable line is the one you can say out loud.

Daylight saving: the two cases where a local time is not an instant

Converting a timestamp into a date is arithmetic. Going the other way is not, because a wall time like 02:30 on a clock is not always the same thing as an instant. Twice a year, in every zone that observes daylight saving, the mapping breaks in one of two ways — and both are visible if you ask for them.

The local time that does not exist

When the clocks move forward, an hour of wall times never happens. In America/New_York on 2026-03-08 the clock goes from 01:59:59 to 03:00:00, so 02:30 never occurs there that day. Anything in that hour is a time someone wrote down by hand, or computed from a naive formula. Press Load the DST example to see it: this tool reports both sides of the gap — 01:30 at offset −05:00 and 03:30 at offset −04:00 — and states which one it used. A converter that quietly returns one of them without mentioning the gap has answered a question you did not ask.

The local time that happens twice

When the clocks move back, an hour of wall times happens twice: 01:30 on 2026-11-01 in New York occurs once at offset −04:00 and again at offset −05:00, an hour apart in real time. The two instants have different Unix timestamps. This tool shows both and uses the earlier one, so a stored value can be checked rather than trusted.

Note what is not here: no list of transition dates. The transitions are read from the browser's time zone data at the moment you use the page, including the change from each offset to the next. That is also why the gap description on the page names the two offsets rather than a general rule.

Negative timestamps, and why 0 is not a blank value

0 is 1970-01-01 00:00:00 UTC — a real instant, and also what many systems return when a date field was never set. This tool converts it and says that both readings of zero give the same moment, because in that one case the unit genuinely does not matter.

Negative values are dates before 1970 and they are ordinary Unix time, not a special format. They turn up when a server clock was wrong and was later corrected, when a value was read as signed and reinterpreted, or when the data deliberately marks a pre-epoch date such as a birth date stored as an offset. The rule for reading them is the same as for positive values and the tool states plainly that the result is before the epoch, because a date in 1969 is easy to mistake for a formatting bug and a wasted afternoon.

The 2038 boundary

On systems that store Unix time in a signed 32-bit integer, the largest representable value is 2147483647, which is 2038-01-19 03:14:07 UTC. The next second does not become 2038-01-19 03:14:08 — it wraps to the negative end of the range and reads as 1901-12-13 20:45:52.

Two things follow, and both are why this is worth a section rather than a footnote:

• It is arithmetic, not a forecast. 2³¹ − 1 is 2147483647; the wrapped value is the same number read in two's complement. Both dates above are computed by this page from those numbers, so you can check them by hand.
• The systems that break are the quiet ones. Desktop and server software moved to 64-bit counters decades ago, but 32-bit fields persist in file formats, embedded devices, protocol headers and old binaries. When you paste a value near the boundary, this page notes it, and for values past it shows the wrapped date — the exact answer an affected system would produce.

Milliseconds do not have this problem: a millisecond counter has always needed more than 32 bits, so no millisecond timestamp was ever stored that way. The warning therefore appears only when the value is read as seconds, which is what makes the unit line matter more than it looks.

What this tool refuses, and why

Every entry below could be computed. Each one would require deciding something the input does not say, so the tool says what it cannot do instead of producing a number that is quietly different from the one you meant.

The last two are calendar arithmetic rather than policy. February has 29 days when the year is divisible by 4, except in century years, except in centuries divisible by 400 — so 2000 had a 29 February and 1900 did not. Leap seconds are added to civil time roughly once every year or two, and because Unix time ignores them, the hour around one can look wrong in any conversion. Knowing that is more useful than a tool that silently maps 60 to nothing.

What leaves this page

Nothing. The page imports one module of pure functions and reads time zone data from your browser; there is no request to our server, no analytics event carrying your value, and no storage of any kind. Close the tab and the numbers you typed are gone.

That does not make every timestamp safe to paste. A timestamp in a log line is often next to a hostname, an account or a token, and the browser's own memory, the clipboard and the screen are all outside what this page controls. The tool shows you what it did; what you keep on your screen is still your call.

Where to go next

• Date and time — this category, and where age, time zone and countdown calculators will land as they are built.
• JSON formatter and validator — for the payload the timestamp came inside, including the exact line and column of a syntax error.
• Date difference calculator — when you have two dates and need the gap between them in days, weeks and working days.

Common questions

How do I know whether my timestamp is in seconds or milliseconds?

You do not have to know: this tool reads both and tells you which one it used. When only one of the two readings lands in a real date (this tool uses 1900-01-01 to 2100-12-31 as its window), that reading is shown and the other is mentioned. When both readings are real dates — a 10-digit number is always in that position, because the same digits read as milliseconds land a few weeks after 1 January 1970 — the tool says so, picks the reading its documented rule implies, and puts the other date next to it so you can compare. If you know your source, set the unit yourself and nothing is inferred.

Why does the date change when I pick a different time zone?

Because a timestamp does not contain a date. It is a count of seconds from a fixed point, 1 January 1970 at 00:00 UTC, and a calendar date only appears once you say which zone you are reading it in. 1757000000 seconds is 15:33 on 4 September 2025 in UTC, 23:33 the same day in Tokyo, and 08:33 the same morning in Los Angeles. None of those is more correct than the others, which is why this tool shows UTC, your own zone, and a zone you choose side by side instead of picking one for you.

Where does the time zone data come from?

From your browser. The page asks Intl.DateTimeFormat for the offset and Intl.supportedValuesOf for the list of zone identifiers, so every offset and every daylight saving transition comes from the same time zone database that the rest of your system uses. Nothing is bundled with the page and no table is maintained by hand here: shipping a copied list of offsets would mean publishing a table that goes stale the next time a country changes its rules.

What exactly is the 2038 problem?

On systems that store Unix time in a signed 32-bit integer, the largest value is 2147483647, which is 2038-01-19 03:14:07 UTC. One second later the value wraps around to the negative end and the date jumps back to 1901. This is arithmetic, not a forecast: 2^31 minus one is 2147483647, and this page computes the wrapped date rather than repeating a claim about it. Modern 64-bit systems are not affected, which is precisely why it hides — the format that breaks is the one still used by some embedded devices, file formats and older binaries.

Can a timestamp be negative?

Yes. Negative values are dates before 1 January 1970, and they are what you see when a clock was wrong, when a date field was read as unsigned and reinterpreted, or when the value deliberately marks a pre-epoch date. This tool converts them like any other value and says plainly that the result is before the epoch, because a negative number is easy to mistake for a formatting bug.

Why does it reject 1.5 or 1e9 instead of rounding?

Because the intent behind them is not in the number. 1.5 could mean one and a half seconds or a mistyped 1500 milliseconds, and rounding it silently turns it into a different instant that still looks like a valid answer. The same applies to a decimal comma, a thousands separator or hexadecimal: they can all be computed, and none of them tells this tool what was meant. Type the plain integer, or switch the unit, and you get an exact result instead of a plausible one.