Timestamp convert.
Paste a Unix timestamp (in seconds, ms, μs, or ns) or an ISO 8601 string. Get every other format back, plus relative time, day-of-week, and your local offset. The clock above ticks live so you can sanity-check "now."
| Unix seconds | 1792320835 | |
|---|---|---|
| Unix ms | 1792320835122 | |
| Unix μs | 1792320835122000 | |
| Unix ns | 1792320835122000000 | |
| ISO 8601 (UTC) | 2026-10-18T10:53:55.122Z | |
| RFC 2822 (UTC) | Sun, 18 Oct 2026 10:53:55 GMT | |
| Local | 2026-10-18 10:53:55 (+00:00) | |
| Relative | 0 seconds ago |
Three traps that bite production.
First, leap seconds. Unix time pretends they don't exist; it has 86,400 seconds in every day, even when UTC inserts an extra one. Most systems handle this with leap-second smearing (Google, AWS): slowing the clock over a window so the discontinuity disappears. If two services use different smear policies, their clocks disagree by up to a second across the boundary. Second, time zones in storage. Always store UTC; do the time-zone shift at render time. The single biggest cause of "appointment shows on the wrong day" bugs is dropping time zone information at write time. Third, daylight saving. Local times jump and repeat. 2025-11-02 01:30 America/Los_Angeles happens twice. Cron jobs scheduled in local time fire either zero or two times across the boundary.
Servers should run in UTC. Logs, databases, and APIs should emit UTC. Convert to local time only at the rendering edge, using IANA time-zone names (America/New_York): never UTC offsets, which don't account for DST.