Unix timestamp converter

Seconds or milliseconds, and why counting digits fails

Nearly every converter decides the unit by length: ten digits is seconds, thirteen is milliseconds. It works most of the time, which is exactly what makes it dangerous — the failures are rare, silent, and land on real dates.

A digit rule reads the first row as milliseconds and returns 2 January 1970 for a perfectly ordinary date in 1973. Ten digits only means seconds from 9 September 2001 to 20 November 2286; outside that window — which includes every second-precision timestamp from the first thirty-one years of Unix time — the rule is simply wrong.

Each unit is tried here instead, and the one whose date lands nearest today wins. All four readings are shown beside the answer, so when the guess is arguable you can see what it decided and change it in one click.

Nanoseconds do not fit in a JavaScript number

Go's time.UnixNano, most tracing systems and several databases hand back nanoseconds. A nanosecond timestamp today is about 1.8 × 10¹⁸. JavaScript numbers are doubles, exact for integers only up to Number.MAX_SAFE_INTEGER, which is about 9 × 10¹⁵ — two hundred times smaller.

No error is raised for that. The value is simply rounded, and a tool built on Number() shows a date that is right to the millisecond and wrong in the last three digits — which is precisely the part you were looking at, if you are working in nanoseconds at all.

Everything here counts in BigInt and narrows to an ordinary number only once the value is in milliseconds, where a double is exact for any date a person will ever type. Microseconds, for what it is worth, stay safe as a plain number until about the year 2255.

The date that moves when you add a time to it

This one catches everybody, and it is specified behaviour rather than a bug:

ECMA-262 requires a date-only string to be treated as UTC and a date-time string without an offset to be treated as local time. Adding a time component you thought was redundant therefore shifts the instant by your whole offset — enough to change the day, the month, the quarter and the financial year.

It cannot be fixed without breaking every page that relies on it, so the only honest thing a tool can do is say which assumption it made. This one does, every time it has to make one. The way to avoid the question entirely is to write the offset down: 2024-01-15T00:00:00Z means one instant everywhere.

The week number that belongs to last year

ISO 8601 numbers weeks by where their Thursday falls, so the first days of January often belong to the previous year's final week. 1 January 2021 is 2020-W53-5. 1 January 2017 is 2016-W52-7.

The classic bug is printing an ISO week number next to a calendar year, which produces a label that does not exist for a few days every year and is noticed twelve months later. The week date shown here carries its own week-numbering year, which is the only form that is ever unambiguous.

2038, and the dates that break software

A signed 32-bit seconds counter runs out at 2147483647 — 03:14:07 on 19 January 2038. One second later it wraps to negative and reads as 13 December 1901. Anything still keeping time in a 32-bit field will hit it: embedded controllers, old database columns, file formats fixed decades ago.

The other end is worse behaved. Pre-1970 dates are negative, and plenty of software stores Unix time unsigned and cannot express them at all — which is how a birth date in 1965 occasionally reappears as 2106. Both conditions are flagged above when your value hits one.

Leap seconds, and why Unix time ignores them

Unix time is defined as if every day contains exactly 86,400 seconds. Leap seconds — inserted to keep clocks aligned with the Earth's rotation, 27 of them so far — are absorbed by repeating a value rather than by adding one.

So the count is not truly elapsed seconds since 1970; it is about half a minute short. That is a deliberate trade. It means converting a timestamp to a date is division rather than a table lookup, and that every day is the same length in arithmetic, which is worth far more than the accuracy given up.

Questions

How do I convert a Unix timestamp to a date?

Paste the number in. The unit is worked out for you — seconds, milliseconds, microseconds or nanoseconds — and every reading is shown so you can pick a different one if the guess is wrong. The date appears in UTC and in whichever zone you choose.

How does it tell seconds from milliseconds?

By which reading lands nearest today, not by counting digits. A digit-count rule says ten digits means seconds, and that is only true from September 2001 to November 2286 — a nine-digit timestamp is an ordinary date before 2001 that gets read as a few days after the epoch instead. Each unit is tried here and the one giving a plausible date wins, with all four shown so the guess is visible rather than assumed.

Why does my nanosecond timestamp come back wrong in other tools?

Because a nanosecond timestamp is around 1.8 × 10¹⁸ and JavaScript can only hold integers exactly up to about 9 × 10¹⁵. A tool that does Number(input) turns 1787000000123456789 into 1787000000123456800 — the last three digits are simply not stored. This counts in BigInt throughout and only narrows to a plain number once the value is in milliseconds, which is small enough to be exact.

Why does adding a time to a date change the date?

Because ECMA-262 says so, and it is the single most surprising thing about dates in JavaScript. 2024-01-15 is read as midnight UTC; 2024-01-15T00:00:00 is read as midnight local. The same date, two instants, as far apart as your offset — in Auckland that is the day before. It cannot be fixed without breaking the language, so this tool tells you which assumption it made every time it has to make one.

What is the 2038 problem?

Unix time in a signed 32-bit integer runs out at 03:14:07 on 19 January 2038. One second later the counter wraps to negative and the date reads as December 1901. It is not hypothetical: any system still storing time in a 32-bit field — embedded controllers, old database columns, file formats — hits it. Timestamps past that point are flagged here.

Does it handle dates before 1970?

Yes, as negative numbers, and it is flagged when it happens. A good deal of software stores Unix time unsigned and cannot represent a pre-epoch date at all, which is why a birth date from 1965 sometimes turns into 2106 in a badly written form.

Does Unix time count leap seconds?

No, and that is deliberate rather than an oversight. Unix time is defined as though every day is exactly 86,400 seconds, so a leap second is absorbed by repeating a value rather than adding one. It means the count is not quite elapsed seconds since 1970 — it is 27 or so short — but it also means a day is always the same length in arithmetic, which is worth far more than the accuracy it gives up.

Is anything sent to a server?

No. Timestamps sit in logs, traces and database rows, and the number itself often gives away when a system did something. The conversion is arithmetic, so it runs in this tab and makes no request.

What BriskFile will not do to you

• Your files never leave your device

  Every conversion runs in your browser. Open DevTools, watch the Network tab, and you will see no upload — because there is not one.

• No account, no email, no watermark

  Nothing to sign up for and nothing stamped on your images. There is no step between choosing a file and getting it back.

• No limits at the download button

  No daily cap, no file counter, no "upgrade to download". If the tool starts a job, it finishes it.

• Checkable, not just claimed

  Open the Network tab and convert something — nothing goes out. Or load the page, disconnect, and watch it keep working: the tool is already on your machine, and your file never leaves it.