Unix Timestamp Converter
Convert between epoch values and human dates, in any time zone.
schedule
1792321619
Convert Unix epoch timestamps to human-readable dates and back, across time zones — the tool you want open while reading a log file.
Unix time counts seconds since 1 January 1970 UTC, and almost every bug involving it comes from one of three things: a value in milliseconds being read as seconds (which lands you in 1970), a local time being treated as UTC, or the assumption that a day is always 86,400 seconds when the local calendar has a daylight-saving transition in it.
This converter shows the same instant as a Unix value, an ISO 8601 string, UTC and your local time side by side, so a mismatch is visible rather than inferred. Second and millisecond inputs are distinguished by magnitude, which is the same heuristic that catches the mistake in the first place.
The 2038 problem is not a historical curiosity. A signed 32-bit seconds counter runs out on 19 January 2038 at 03:14:07 UTC and wraps around to 1901. Most desktop and server software moved to 64-bit time years ago, but the limit is still built into places that are easy to forget: a MySQL TIMESTAMP column accepts 1970 to 2038 and nothing outside that range, while DATETIME has no such bound, and embedded firmware with a 32-bit clock will keep shipping for years yet. Dates far in the future are where the boundary is met first — an expiry, a mortgage term, a certificate lifetime — long before 2038 itself arrives. If a value here converts to 1901, or to a date in 1970, an overflow or a seconds-versus-milliseconds mix-up is almost always the reason.
Unix time is not a count of elapsed seconds, which catches out people who assume that it is. A POSIX day is defined as exactly 86,400 seconds, so the leap seconds inserted into UTC since 1972 simply do not appear in the number. Subtracting two Unix timestamps that straddle one therefore gives an interval a second shorter than the physical truth, and systems disagree about what to do with the extra second: some repeat a value, others slow their clocks across the whole day to absorb it. None of this matters for scheduling, or for durations measured in minutes. It matters when something measures an interval to the second across years, which is exactly the case where nobody thinks to check.
ISO 8601 and RFC 3339 are not interchangeable, and the difference shows up as a parser rejecting a string that looks perfectly fine. RFC 3339 is a narrow profile — a full date, a time, and an offset, as in 2026-08-24T09:30:00+09:00, or the same instant written with a trailing Z for UTC. ISO 8601 is much broader, permitting week dates, ordinal dates and a compact form with the separators removed, most of which a JSON API will refuse. It is worth separating an offset from a time zone as well: +09:00 records what a clock read at one moment, while Asia/Seoul records the rules, and only the second survives a daylight-saving transition or a government revising its offset.
Dates before 1970 are negative Unix timestamps, and support for them is inconsistent enough to be worth testing rather than assuming. The arithmetic is well defined — a birth date in 1965 is simply a negative number of seconds — but plenty of code paths were written on the assumption that the value is unsigned, and they respond by producing a date in 2106, rejecting the input, or storing zero. This page converts negative values normally, which makes it a quick way to find out whether an unexpected 1970 or 2106 in a system is a storage limit or a conversion bug.
Midnight UTC on 1 January 1970. A Unix timestamp counts the seconds elapsed since then, ignoring leap seconds.
A signed 32-bit timestamp overflows in January 2038. Modern systems use 64-bit values, but old file formats and embedded devices can still be affected.
Yes — a negative value is a date before 1970 and converts normally.