Unix Timestamp Converter

A Unix timestamp is the count of seconds (or milliseconds) that have elapsed since 00:00:00 UTC on 1 January 1970 — the Unix epoch defined by POSIX. It is the most widely used time representation in software because a single integer is unambiguous, sortable, comparable in constant time, and free of timezone metadata. Filesystems, databases, log formats, JWT claims, HTTP cache headers, and almost every API expressing a moment in time use it.

This converter is built entirely on the browser's native Date object. Date.now() returns the current time as milliseconds since the epoch; new Date(ms) constructs a Date from milliseconds; toISOString(), toUTCString(), and toLocaleString() emit the three most common readable formats. The seconds-vs-milliseconds heuristic is simple — values at or above 10^12 (the first 13-digit timestamp, Sep 2001 in milliseconds) are treated as milliseconds, since any seconds-based timestamp that large would be far in the future.

Time-zone conversion is delegated to Intl.DateTimeFormat under the hood (toLocaleString supports a timeZone option that follows the IANA time-zone database). The dropdown lists eleven common zones; any IANA identifier — Europe/Helsinki, Asia/Singapore, Pacific/Auckland — works if you wire it in. Daylight saving transitions are honored automatically because the IANA database tracks rules per zone and per year.

There is a famous limitation worth understanding: the Year 2038 problem. A 32-bit signed integer can hold timestamps only up to 2,147,483,647 seconds, which is 03:14:07 UTC on 19 January 2038. Beyond that, 32-bit systems wrap around to negative numbers, breaking systems that still use time_t as a 32-bit value (some embedded firmware, older databases, old C code). Modern Linux, macOS, Windows, and JavaScript all use 64-bit integers and are safe through year 292 billion, but the 2038 cutoff still appears in legacy infrastructure.

ISO 8601 is the format you should standardize on for cross-system communication: YYYY-MM-DDTHH:mm:ss.sssZ. The trailing Z signals UTC; replacing it with an offset like +05:30 or -08:00 conveys local time without ambiguity. Avoid month-day-year shorthand (1/2/24 means different things on different sides of the Atlantic) and avoid plain HH:mm strings without a date or zone — they cannot be parsed without ambient assumptions.

The Date constructor's parser is famously lenient about ISO 8601 but inconsistent on free-form input. "Jan 15 2024" parses on most engines; "2024-1-1" might or might not; "15/01/2024" is interpreted as US-format and produces wrong results in many cases. For production parsing where the input format is known, prefer date-fns parse, Day.js custom parse, or Temporal.PlainDateTime.from once it ships. This converter uses the built-in parser because the use case is exploratory.

Everything runs locally. The current-time display is driven by setInterval ticking every second; the conversions are pure functions of input. No server is contacted, no analytics collected. Closing the tab discards the inputs.