Methodology. How This Epoch Converter Handles Edge Cases
Every conversion on this site is pure arithmetic in your browser. This page documents the exact rules for the edge cases — negative timestamps, fractional seconds, leap seconds, unit auto-detection, and daylight saving — and the specifications they follow.
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)
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 digits or more → microseconds
This is a heuristic, which is why the Auto / sec / ms / µs chips let you override it for ambiguous values, and why every result row shows the reading in all three units so a misread is immediately visible.
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
- POSIX.1-2024 — seconds since the Epoch
- RFC 3339 — date and time on the internet
- IANA — the Time Zone Database
- IERS Bulletin C — leap seconds
Last reviewed · Maintained by the Real Epoch Converter team · Contact