- How does the unit auto-detection work?
- It counts digits. A 10-digit positive integer is seconds (good through the year 2286), 13 digits is milliseconds, 16 is microseconds, and 19 is nanoseconds. Negative values (pre-1970) work the same way after stripping the sign.
- When should I use ns versus ms?
- Use milliseconds when you only need wall-clock accuracy and the value will land in a Date / Instant / Timestamp object — that is most application code. Use microseconds or nanoseconds when ordering matters at sub-millisecond resolution: tracing spans, metrics ingestion, columnar databases like ClickHouse, and Go services calling time.Now().UnixNano(). Storing nanoseconds when you only need seconds wastes index space and complicates joins across systems that downsample.
- What’s the year-2038 problem?
- Systems that store Unix seconds in a signed 32-bit integer overflow at 03:14:07 UTC on 19 January 2038 — the value 2_147_483_647 + 1 wraps to a large negative number. The fix is to use a 64-bit integer (or unsigned 32-bit if you only care about the future), which every modern language and database already does. This tool internally uses BigInt, so it has no 2038 cliff.
- Does this preserve nanosecond precision?
- Yes in the ISO 8601 row, which is built from BigInt arithmetic and can show all nine fractional-second digits. The UTC string and local string rows are formatted by JavaScript’s Date, which is millisecond-resolution, so anything sub-millisecond rounds in those rows.
- What about leap seconds?
- Unix time, by design, ignores them — every day is treated as 86_400 seconds even when UTC has inserted a leap second. See the glossary entry on the leap second for the longer story. If you need true UTC including leap seconds, you need TAI or a leap-second-aware library, not a plain epoch value.
- Is anything sent to a server?
- No. Parsing, BigInt math, and formatting all run in your browser. The page makes no network requests when you paste a timestamp.