About Epochly

Epochly is a single-purpose converter for Unix timestamps. It exists because the everyday version of this task — pasting a number into a search box and hoping the first result guessed the same unit you did — has no way of telling you why it produced the date it produced. When a timestamp renders as 1970 or as the year 55840, the useful output is not a date. It is an explanation.

How the unit is decided

The converter counts the digits before any decimal point, ignoring the sign, whitespace, underscores and thousands separators, and maps that count onto a unit:

• 1–11 digits → seconds
• 12–14 digits → milliseconds
• 15–17 digits → microseconds
• 18–20 digits → nanoseconds

The windows work because multiplying by a thousand adds exactly three digits, so the same instant written in seconds, milliseconds and microseconds is 10, 13 and 16 digits long. Each window is padded by one digit either side to absorb older values and future ones. The verdict, and the reasoning behind it, is printed above the results on every page — and the s / ms / µs / ns buttons override it when you know something the digit count does not. The complete digit-to-date map is tabulated on the timestamp to date page.

What it outputs, and why those four

• ISO 8601 in UTC — the interchange format. Sorts as text in the same order it sorts chronologically, which no other common format does.
• RFC 2822 — the email Date: format, written with the numeric +0000 offset the specification calls for. This is deliberately not Date#toUTCString(), which produces the superficially similar HTTP-date form ending in the word GMT.
• Local time with the IANA zone named — your browser resolves the zone identifier and the page prints it in full. Zone abbreviations are not used because they are ambiguous; CST alone is several different offsets depending on the continent.
• Relative — a distance rather than a measurement. Seconds, minutes, hours and days are exact; months and years use 30-day and 365-day approximations, which is stated here rather than implied.

Calendar assumptions

Three assumptions are baked in, all of them shared with Unix time itself. First, every day is exactly 86,400 seconds — leap seconds are not represented, which is what makes timestamp arithmetic plain division. Second, the calendar is the proleptic Gregorian one, so the modern leap-year rule is applied backwards through dates that were historically Julian. Third, the representable range is the ECMAScript time-value range of ±8.64e+15 milliseconds, roughly ±273,790 years around 1970; values outside it are refused with an explanation rather than shown as "Invalid Date".

Where a value exceeds what a double-precision float can hold exactly — Number.MAX_SAFE_INTEGER is 9007199254740991, sixteen digits — the arithmetic behind the published tables is done with BigInt so that 16- and 17-digit values are not silently rounded. The interface reports instants to millisecond resolution and does not claim more.

How the published numbers are produced

Every date, offset and range printed in a table on this site is computed at build time from the same functions the tool uses, then asserted against literal expected values in a test suite that runs before release. That includes the epoch milestones, the digit-length windows, the eleven-zone offset table, the Discord style tags and the Excel constant. Nothing is transcribed from memory, and a wrong value fails the build instead of shipping.

The Excel offset is a good example of the standard applied: 25569 is not asserted, it is derived — the true day count from 1900-01-01 to 1970-01-01 is 25,567, a correct calendar would put 1970-01-01 at serial 25,568, and Excel's phantom 1900-02-29 adds the final day. The derivation is on the home page and the test checks all three numbers.

What Epochly does not do

• It does not correct your clock. The live readout is whatever your operating system reports. Contacting a time server would mean making a network request from a page that otherwise makes none, which is a trade this site does not take.
• It does not model leap seconds. If you need UTC with leap seconds represented — astronomy, some financial and scientific timekeeping — a Unix timestamp is the wrong container and no converter can add the information back.
• It does not guess your intent on ambiguous local times. On a daylight-saving spring-forward gap, a wall clock that never happened resolves to the instant the clock jumped to; on an autumn overlap, one of the two possible instants is chosen. Both behaviours are documented on the date to timestamp page rather than hidden.
• It does not store anything. No accounts, no history, no cookies set by the tool, no local storage. Reload the page and it is back to its preset.

Privacy in one sentence

Every conversion is arithmetic performed by JavaScript inside your browser, and the value you paste is never transmitted — there is no backend to transmit it to. Production timestamps are frequently sensitive, so this is a design constraint rather than a courtesy. The full statement, including the third-party advertising disclosure, is on the privacy page.

Where to go next

• Unix timestamp converter — the bidirectional tool and the ten-language cheat sheet.
• Unix timestamp to date — the decode direction and the digit-length table.
• Date to Unix timestamp — the encode direction and the eleven-zone spread.
• Milliseconds to date — 13-digit values and the unit mix-up table.
• Current Unix timestamp — the live count and the epoch milestones.
• Discord timestamp generator — all nine style suffixes.

Corrections are genuinely welcome, particularly on the language cheat sheet — if a snippet is not the idiomatic form in a language you use daily, say so through the contact page.