Unix timestamp converter

A Unix timestamp is a count of seconds since 1 January 1970 UTC. JavaScript, Java and most log pipelines count milliseconds instead. So the same digits mean two moments that can be decades apart, and nothing about the number itself says which convention produced it.

The size settles it in practice. A ten-digit value is seconds until the year 2286; a thirteen-digit value has been milliseconds since 1973. This page picks on that basis and then tells you what it picked, which is the part most converters leave out — one that guesses silently and guesses wrong shows a date in January 1970 with no explanation attached.

UTC is the timestamp itself: an epoch value carries no zone, so the UTC rendering is a fact rather than a choice. The local line is your device setting, and the offset is printed beside it so it is never left implied.

That distinction matters more than it looks when the number came from somewhere else. A timestamp out of a production log refers to a moment, and the moment is the same everywhere — but the wall-clock time your colleague quotes from the same log is in their zone, and comparing the two by eye is where an hour goes missing. Compare the UTC line, or compare the number.

ISO 8601 with a trailing `Z` is unambiguous: it names the moment, the zone and the precision in one string, and every language parses it. `2023-11-14T22:13:20.000Z` cannot be misread as a day-month-year or a month-day-year, which the same date written with slashes very much can.

That ambiguity is not theoretical. `03/04/2024` is 3 April in most of the world and 4 March in the United States, and a spreadsheet will silently interpret it according to its own locale. If a date is going into a ticket, a message or another system, the ISO form is the one that survives the trip.

ISO 8601 weeks start on Monday, and week 1 is the week containing the first Thursday of the year. That means 1 January can belong to week 52 or 53 of the *previous* year — 1 January 2021 is in 2020-W53 — and that a year can have 53 weeks.

The obvious implementation, dividing the day of the year by seven, disagrees with that for a fortnight every year. It matters because ISO weeks are what reporting tools, payroll systems and most of Europe use, so a report labelled "week 1" can cover days in two different years and be entirely correct.

A signed 32-bit integer holding seconds overflows on 19 January 2038. Systems still using `time_t` as a 32-bit value will wrap to 1901 — the same shape of problem as the year 2000, with a narrower blast radius and a harder fix, because it is embedded firmware and old file formats rather than business software.

It does not apply to anything on this page or to anything written in the last decade in a mainstream language. JavaScript uses a double, which holds milliseconds exactly to the year 275760. Sixty-four-bit `time_t` covers longer than the universe has existed. If you are looking at a timestamp in a browser, 2038 is somebody else problem.

A date in 1970 nearly always means milliseconds were read as seconds — or that the value was zero or empty and something coerced it to zero, which is the epoch itself. A date in the far future usually means the reverse: seconds read as milliseconds, or a timestamp in microseconds or nanoseconds, which some databases and tracing systems emit.

Microseconds are sixteen digits and nanoseconds nineteen. Neither is handled automatically here, because both are rare enough that guessing them would make the common guess worse. Divide by a thousand or a million first, and the value falls into a range this page reads correctly.