Unix Time Precision Converter
Convert a timestamp between seconds, milliseconds, microseconds, and nanoseconds since Unix epoch.
- seconds (s)1792363586
- milliseconds (ms)1792363586000
- microseconds (µs)1792363586000000
- nanoseconds (ns)1792363586000000000
- UTC2026-10-18 22:46:26.000 UTC
- ISO 86012026-10-18T22:46:26.000Z
- RFC 2822Sun, 18 Oct 2026 22:46:26 GMT
- LocalSun Oct 18 2026 22:46:26 GMT+0000 (Coordinated Universal Time)
- Relative4s ago
Auto-detect uses magnitude (~10^9 = s, ~10^12 = ms, etc.). Override if your timestamp is far past/future.
How to use
- Paste a number — commas, underscores, and whitespace are stripped.
- Auto-detection picks s/ms/us/ns by magnitude. Override with the dropdown if it's wrong.
- All four precisions and four datetime formats display side-by-side. Copy whichever your destination expects.
About this tool
ShowHide
Different systems count Unix time at different resolutions, and the number rarely says which. PostgreSQL's now() is microseconds, Date.now() in JavaScript is milliseconds, Go's time.Unix() takes seconds, gRPC's Timestamp carries seconds plus nanos, Prometheus uses float seconds, syslog goes to nanoseconds. Paste a number and this tool guesses the unit from its magnitude, shows the value at all four precisions, and renders it as ISO 8601, RFC 2822 in UTC, your local time and a relative "ago" string. Override the guess when you already know the source.
The guess works because a current timestamp has a characteristic length: right now seconds are ten digits, milliseconds thirteen, microseconds sixteen and nanoseconds nineteen. That is a heuristic about the present, not a property of the format, and it fails on old or synthetic values. The number 1000000000 is a Thursday in September 2001 read as seconds and a Monday in January 1970 read as milliseconds; both are legitimate and only you know which log wrote it. A timestamp near zero is the most ambiguous of all, which is why a suspiciously 1970 date usually means the unit was misread rather than that something is genuinely that old.
Three ceilings are worth knowing. A signed 32-bit count of seconds runs out on 19 January 2038 at 03:14:07 UTC, which is still the storage type in plenty of embedded systems and old database columns. A signed 64-bit count of nanoseconds — Go's UnixNano, among others — runs out in April 2262, which sounds remote until you compute a far-future expiry date and get an overflow. And JavaScript numbers hold integers exactly only to 2^53, which is 9,007,199,254,740,992 nanoseconds, about 104 days after the epoch: nanosecond timestamps cannot be represented as a JavaScript number at all and must travel as a string or a BigInt.
One thing no precision fixes: Unix time ignores leap seconds by construction. A leap second is absorbed rather than counted, so the same Unix timestamp covers two real seconds when one is inserted, and a duration computed by subtracting two timestamps across such a moment is off by a second.
Frequently asked questions
How does auto-detection work?
Modern timestamps fall in predictable magnitude ranges: a unix-seconds value for 2026 is around 1.78×10^9, ms is 1.78×10^12, us is 1.78×10^15, ns is 1.78×10^18. We pick the precision whose decade range your number falls into. Override if the value is unusual (e.g. a future date 100 years out).
Why might microsecond/nanosecond outputs lose precision?
JavaScript Number is a 64-bit float with 53 bits of mantissa — enough for ms precision over Date's full range, but ns values past 2^53 lose precision in the lower digits. For exact nanosecond math at large values, use a library like BigInt or display only the relevant digits.
What's the relative time based on?
Your browser's current time at page render. Refresh to update. Useful for sanity-checking whether a log timestamp is recent or old.
How do I stop a timestamp being read at the wrong precision?
Say which unit you mean, in the field name or the schema, rather than letting the receiver infer it — created_at_ms is unambiguous where created_at is a guess. Detection works on magnitude, so it is reliable for today's dates and fails exactly where it matters: a second-precision timestamp from the 1970s and a millisecond one from now can occupy the same range of values.
Why do the microsecond and nanosecond values lose their last digits?
Because a double holds integers exactly only up to about nine quadrillion, and a nanosecond timestamp for any current date is larger than that. The last few digits are therefore not preserved. Carry nanosecond times as strings or as a big-integer type, and treat a nanosecond value that arrived through JSON as suspect unless it was quoted.
Related tools
Unix Timestamp Converter
Convert Unix timestamps to dates and dates back to timestamps.
Time
Epoch Time Converter (Unix, FILETIME, Excel)
Convert one moment in time between 11 epoch formats — Unix seconds and ms, NTP, Windows FILETIME, .NET Ticks, Mac HFS+, Excel serial, ISO 8601.
Time
Date Format Converter
Type any date (ISO, RFC, Unix epoch, locale) and see it rendered in 14+ standard formats side by side.
Time
Duration Formatter
Convert a duration between human ("1h 30m"), clock (1:30:00), ISO 8601 (PT1H30M), and raw seconds/minutes/hours/days.
Time
GPS Time, TAI and Leap Second Converter
Convert UTC to GPS week and time of week, TAI and the GPS−UTC offset, with every leap second since 1972 listed.
Time
Duration Calculator
Add and subtract time durations in hours, minutes and seconds — get the total as h:m:s plus decimal hours, total minutes and total seconds.
Time