Unix Timestamp Converter

The factor-of-a-thousand bug

This is the mistake the tool exists to catch. Java, JavaScript and most JVM libraries count epoch time in milliseconds; Unix time(), Postgres extract(epoch), Go's Unix() and Python's time.time() count seconds. Mix them and a timestamp read as the wrong unit lands either in January 1970 or somewhere around the year 57000 - obviously wrong when you look at it, and invisible when it is stored in a column nobody reads.

Unit detection here works by magnitude and is always shown rather than applied quietly, so you can see that a value was read as milliseconds and override it if that was not what you meant. A tool that guesses silently and gets it wrong produces a confidently wrong date, which is worse than asking.

Timezones, correctly

Conversion uses the IANA timezone database built into your browser, so daylight-saving transitions are handled with the same data your server almost certainly uses rather than with a hard-coded offset that goes stale. The result is shown in your own zone plus IST, UTC, New York, London, San Francisco and Singapore, with each zone's current offset displayed - because a bug report that says 19:41 is only actionable once you know which 19:41 it was.

• Seconds, milliseconds, microseconds and nanoseconds
• ISO-8601, epoch seconds, epoch milliseconds and the HTTP Date format
• Relative rendering - three hours ago, in two days
• Weekday, day of year, ISO week number and whether it is a leap year

Two parsing rules worth memorising

An ISO string with no offset and no Z is ambiguous: it names a wall-clock time, so the same string is a different instant depending on where it is read. Always write an offset or a Z when the value crosses a system boundary.

And a bare date like 2026-07-29 is parsed as midnight UTC, while 2026-07-29T00:00 is parsed as midnight local. That asymmetry is specified behaviour rather than a browser quirk, and it surprises everybody exactly once - usually as an off-by-one-day bug in a date filter.

What it will not do

It does not parse non-ISO date text. Formats like 29/07/2026 are genuinely ambiguous between day-first and month-first conventions, and any behaviour on such input would be a guess about your intent, so they are refused rather than interpreted. Paste an epoch or an ISO string.

It also does not convert between calendars, does not handle leap seconds - Unix time simply does not represent them - and does not do date arithmetic. It converts one instant at a time.