Epoch converter that works out the unit

Count the digits: ten means seconds, thirteen means milliseconds, and there is no overlap between them for any date you will meet at work. The rule generalises to 10^11, 10^14 and 10^17 as the boundaries between seconds, milliseconds, microseconds and nanoseconds, and all three cut-offs land on 16 November 5138 — so the reading is unambiguous for another three thousand years. The field above applies exactly that test and prints the digit count so you can see the reasoning rather than trust it.

Because a millisecond value was read as seconds, which shrinks it by a factor of a thousand and drops it back to the first fortnight of the epoch. A modern millisecond timestamp of 1700000000123 read as seconds would be the year 55,841, absurd enough that converters guard against that direction; the failure you actually get is the quiet one, 1700000000 read as milliseconds, which is 20 January 1970 at 16:13. If a value keeps arriving as 1970-01-01T00:00:00 exactly, the number reaching the converter is zero — usually an empty string or a null that something coerced.

It counts backwards from 1 January 1970, so -86400 is 31 December 1969 and -2208988800 is the start of 1900. Negative values are ordinary arithmetic, but plenty of code mishandles them: an unsigned column silently wraps them to enormous positives, and integer division that truncates toward zero rather than toward the past puts the result a second out. Birth dates and historical records are where this bites, and it is worth checking that whatever stores them is signed.

Because a single instant falls on two different calendar dates for anyone more than a few hours from Greenwich. An event at 23:31 UTC is already the next morning in Tokyo and still the same afternoon in Los Angeles, so a query grouped by date returns different totals depending on whose midnight it uses. That is the argument for storing the epoch integer and applying a zone only when something is displayed, and the two columns here exist to make the size of the gap obvious at a glance.

Yes — every value here is carried through BigInt rather than a floating-point number. A double runs out of exact integers at 9,007,199,254,740,991, which is June 2255 read as microseconds and only 15 April 1970 read as nanoseconds, so a nanosecond timestamp pushed through JavaScript arithmetic quietly loses its final digits. That is why a Go UnixNano value pasted into most converters comes back with zeros on the end, and why the values above keep all nineteen digits.

The converter says so instead of picking silently. Turning a calendar date into an epoch value needs a time zone, and twice a year a zone either deletes an hour or repeats one: 02:30 on the spring change never existed in New York, and 01:30 on the autumn change happens twice, an hour apart. The date-to-epoch panel names both cases and, for the repeated hour, gives you the second instant as well as the first.

Up to 500 lines in one paste, each measured on its own so a column of mixed seconds and milliseconds still comes out right. The table it produces copies as tab-separated text, which pastes straight into a spreadsheet column or a Markdown table. Nothing about the batch touches the network — the same JavaScript that handles one value handles five hundred.