Methodology. How This Epoch Converter Handles Edge Cases

Where the arithmetic happens

All conversions run in your browser. There is no backend: no timestamp is ever sent to a server, and every result is computed from fixed epoch constants and the Intl timezone data bundled with your browser. Two consequences follow. First, the site is deterministic — the same input produces the same output for every visitor. Second, "now" values (the tickers, the Year 2038 countdown, and the Now buttons) come from your device's clock, not from a server clock.

Negative timestamps

Timestamps before 1970 are ordinary numbers and are fully supported. The main converter, the batch converter, and every specialist tool accept a leading minus sign and render pre-1970 dates correctly (for example -86400 is 1969-12-31 00:00:00 UTC). Integer-only formats such as LDAP, .NET ticks, and snowflake IDs reject negative values with an explanatory error, because those encodings are defined as non-negative counters.

Fractional seconds

Formats that are defined with fractional precision accept them: NTP seconds, Cocoa seconds, and Excel OADate serials (where the fraction is the time of day) all take decimal input, and the main converter accepts fractional seconds in any unit. Formats that are defined as whole numbers — LDAP 100-nanosecond ticks, .NET ticks, HFS+ seconds, GPS weeks/seconds, snowflake IDs, and hex — validate against a digits-only rule and explain what you typed wrong rather than silently truncating.

Leap seconds

POSIX/Unix time ignores leap seconds: by definition, every day has exactly 86,400 seconds, which is what POSIX.1 requires of time_t. The GPS time scale, by contrast, counts the leap seconds that have actually occurred: the GPS clock currently runs 18 seconds ahead of UTC. The GPS converter applies that offset — sourced from IERS Bulletin C, last changed on 2017-01-01 — and exposes it as an editable field so it can be updated the moment the next leap second is announced.

Unit auto-detection (seconds / milliseconds / microseconds / nanoseconds)

The main converter guesses the unit from the magnitude of the integer part only — fractional digits are ignored so a value like 1722750000.5 is read as seconds, not milliseconds:

10 digits or fewer → seconds (fits until late 2286)
11–13 digits → milliseconds (the Date.now() range)
14–16 digits → microseconds
17 digits or more → nanoseconds

Those thresholds drift upward as the decades pass, because every unit is a count of the same growing number: a seconds count reached 10 digits in 2001, and the same instant is 13 digits in milliseconds, 16 in microseconds and 19 in nanoseconds. A rule written against today's values therefore slowly misreads tomorrow's, which is why the Auto / sec / ms / µs / ns chips let you override it for any value, and why every result row states the reading in all four units so a misread is visible immediately rather than silent.

Sub-second values are scaled with exact integer arithmetic

A 19-digit nanosecond value is around 1.8 × 10¹⁸. JavaScript numbers are 64-bit floats that store integers exactly only up to about 9.0 × 10¹⁵, so such a value is roughly two hundred times past the point where it can be represented. Reading one in with parseFloat and dividing by a million does not raise an error — it simply returns a number whose low digits have been rounded away, and the calendar reading still looks plausible because the milliseconds happen to survive. That is the worst kind of failure: a wrong answer that looks right.

So every sub-second conversion on this site scales with BigInt integer division and remainder rather than by dividing a float. Whole seconds are truncated toward zero and the leftover is reported as a sub-microsecond remainder instead of being rounded into the neighbouring value: 1786060800123456789 ns is 1786060800123456 µs plus 789 ns, not 1786060800123457 µs. The nanosecond converter applies the same rule in both directions and rejects a tenth fractional digit outright, because a nanosecond clock has nowhere to put it.

Date parsing and timezones

On the main converter, a date string without an explicit zone is interpreted in the browser's local timezone (the same rule JavaScript's Date parser uses), while ISO strings carrying Z or an explicit offset are read as given. The timezone converter is stricter by design: it accepts ISO-style input only, so the wall-clock time can be anchored to the source zone you selected — accepting loose formats would silently assume your local zone and produce a wrong answer. All zone math goes through Intl.DateTimeFormat with IANA names from the tz database embedded in your browser.

Daylight saving transitions

Offsets are never assumed: for every conversion the correct offset for that exact moment is looked up, so a July value gets the summer offset and a January value the winter one for the same zone pair. Converting a wall-clock time back to an instant iterates twice so the correct offset converges even across a DST boundary. Two genuine ambiguities exist: an hour that does not exist (spring-forward) and an hour that occurs twice (fall-back). Both resolve to the nearest valid reading, and the offset rows shown alongside the result make the chosen interpretation explicit.

Precision and range

JavaScript numbers are exact up to 2^53, so 15-digit epoch-millisecond values are safe. Anything larger — snowflake IDs, LDAP values, .NET ticks — is parsed with BigInt so no precision is lost. Values that fall outside the representable date range (±100,000,000 days) are rejected with an error instead of producing garbage. The "Now" buttons and the live tickers refresh from the device clock; the Year 2038 countdown targets 2,147,483,647 seconds (2038-01-19 03:14:07 UTC), the signed 32-bit maximum.

Specifications referenced on this site

Last reviewed 2026-09-26 · Maintained by the Real Epoch Converter team · Contact