Unix Timestamp Converter

How to use the unix timestamp converter

Paste a timestamp and the panel gives you the same instant four ways at once: the ISO 8601 string, the UTC calendar reading, the same moment in your own browser time zone, and the day of the week. The conversion runs in the page, so nothing you paste is uploaded anywhere.

The first thing the tool tells you is which unit it assumed. That matters more than it sounds. A count of seconds and a count of milliseconds look identical apart from length, and getting it backwards moves the answer by a factor of 1000, which at 2026 scale is the difference between next January and the year 57971.

The second thing worth reading is the pair of zone rows. A Unix timestamp has no zone in it, which is exactly why it is a good storage format and a bad display format. The number is the same everywhere on earth, and the calendar reading of it is not.

Going the other way, the direction switch turns a calendar date into epoch seconds, and it asks you whether the clock you typed is UTC or your own local time. That question is not pedantry. It is the single most common source of an off-by-one-day bug in a date range query.

Negative timestamps work too. They count backwards from 1970, so -1 is 1969-12-31T23:59:59Z. They are perfectly legal, but a fair number of libraries and database drivers reject or mangle them, so check your storage layer before you rely on one for a historical date.

What actually breaks on 19 January 2038?

A signed 32-bit integer holds values up to 2 to the power of 31 minus 1, which is 2147483647. Read as seconds since the epoch, that lands on 2038-01-19T03:14:07Z, a Tuesday. One second later the counter has nowhere to go and wraps to the most negative value it can hold, which reads as December 1901.

This is not a hypothetical for later. Any system that computes a date in the future crosses the line long before the date itself arrives. A thirty year mortgage schedule, a certificate expiry, or a retention policy measured in decades all hit it today, which is why the failures started surfacing years ago rather than waiting for 2038.

The fix is simply a wider integer, and most of the work is done. Linux, the BSDs, macOS and modern Windows all use a 64-bit time value on 64-bit builds. What is left is the long tail: embedded firmware, older 32-bit builds, file formats with a fixed 32-bit field, and database columns typed as a four-byte integer years ago.

The practical test is cheap. Set a date past 2038-01-19 in a staging environment and see what your stack does with it. If a value comes back in 1901, or a query silently returns nothing, you have found a 32-bit field, and you have found it while there is still time to widen it.

Why Unix time is not a true count of elapsed seconds

Unix time is defined so that every day contains exactly 86400 seconds. That is a modelling choice, not a measurement, and it is written into the standard: POSIX defines seconds since the epoch by a formula built from the calendar date, with no term for leap seconds anywhere in it.

Earth rotation is not that tidy, so UTC inserts a leap second when the gap grows too large. Twenty seven of them have been added since 1972, and the offset between International Atomic Time and UTC has stood at 37 seconds since the start of 2017. Atomic time counts every one of those seconds. Unix time counts none of them.

The consequence is concrete. A Unix timestamp during a leap second is ambiguous, because the same number has to serve two different real instants, and most systems handle it by repeating or smearing a second rather than by numbering it. Subtracting two timestamps across a leap second therefore gives you a duration that is off by one second per leap second in between.

It is also worth knowing the direction of travel. In 2022 the General Conference on Weights and Measures resolved to stop inserting leap seconds by 2035, which would let UTC drift further from earth rotation and remove the ambiguity that Unix time has been quietly papering over for fifty years.

The formula, worked line by line

There is no arithmetic worth the name here, which is precisely the appeal of the format. A Unix timestamp is a single integer, and every calendar reading of it is a rendering step rather than a calculation. That is why it sorts correctly as a number, compares with a single operator, and survives being written to any storage that holds integers.

The only two decisions the tool makes are which unit your number is in, and which time zone to render the answer in. Both are stated on screen rather than assumed silently, because both are places where a converter can be confidently wrong.

milliseconds = seconds x 1000
instant = 1970-01-01T00:00:00Z + timestamp seconds
auto-detect: abs(value) >= 100000000000 reads as milliseconds, otherwise seconds
signed 32-bit ceiling = 2^31 - 1 = 2147483647 seconds
unsigned 32-bit ceiling = 2^32 - 1 = 4294967295 seconds

The zone question is the other half. ECMA-262 says a date and time string with no offset is read as local time, while a date on its own is read as UTC. That single rule is why new Date("2026-03-01") and new Date("2026-03-01T00:00") can be different instants in the same program.

This tool refuses to leave that implicit. When you convert a calendar date into a timestamp, you pick whether the clock you typed means UTC or your own wall time, and the answer moves by your offset accordingly. For anyone in London in July that is one hour, and for anyone in Auckland it is thirteen.

One last practical note on precision. Milliseconds are enough for logs and user-facing timing, but they are not enough for high-rate tracing, which is why microsecond and nanosecond epoch counts also exist. A 19-digit number is nanoseconds, and dividing it by a billion rather than a thousand is the fix.

Questions people ask