Unix Timestamp Converter

A timestamp is a number representing a single instant in time, agreed by convention to count from a specific origin called the **epoch**. The Unix epoch — midnight UTC on 1 January 1970 — is the dominant convention in computing today: it is what every Unix-derived operating system, every database (in seconds, milliseconds, or microseconds), and every modern programming language uses as its native time representation. Storing time as "seconds since 1970" instead of "year 2024, June 1, 12:00 PM" eliminates time-zone confusion, daylight-saving anomalies, calendar reform headaches, and locale-specific date formatting — at the cost of being incomprehensible to humans without conversion.

The trick to using timestamps fluently is recognizing the unit. JavaScript's `Date.now()` returns milliseconds since the epoch (13 digits in the current century). Python's `time.time()` returns seconds with a fractional part (10 digits + decimal). Go's `time.Now().Unix()` returns seconds as an int64 (10 digits). PostgreSQL's `EXTRACT(EPOCH FROM …)` returns seconds. MongoDB's `Date` type and Kafka's record timestamps use milliseconds. Tracing tools like OpenTelemetry use nanoseconds (19 digits) for sub-millisecond resolution. The converter auto-detects by magnitude: under 10¹¹ is seconds, under 10¹⁴ is milliseconds, under 10¹⁷ is microseconds, and beyond that is nanoseconds. This mapping covers every realistic timestamp you will encounter.

For human-readable output, the modern standard is **ISO 8601** — `2024-06-01T12:00:00Z`. It puts the most significant unit first (so strings sort correctly), uses fixed-width fields, and uses `Z` or an explicit offset (`+05:30`) to disambiguate time zone. ISO 8601 is what every database accepts in string form, what every API contract should specify, and what every log file should record. The older **RFC 7231** format (`Sat, 01 Jun 2024 12:00:00 GMT`) survives because HTTP requires it in the `Date`, `Last-Modified`, and `Expires` headers, and because email metadata uses a close cousin (RFC 2822). Both formats describe the same instant; ISO is for code, RFC is for protocol headers.

**Time zones** are a separate axis. A Unix timestamp is unambiguous because it is by definition UTC. ISO 8601 strings can be UTC (the `Z` suffix), have an explicit offset (`+05:30`), or — dangerously — have no zone information at all, in which case different parsers will interpret them differently. The local-time row in the converter applies your operating system's current zone rules, including any pending daylight-saving transition. JavaScript's built-in `Date` cannot represent an arbitrary named zone; for that you need a library like `date-fns-tz` or `luxon`.

One practical hazard: the **Year 2038 problem.** Unix seconds counted as a signed 32-bit integer overflow on 19 January 2038 at 03:14:07 UTC. Most modern code uses 64-bit integers and is unaffected, but legacy embedded systems and unpatched older databases still hit it. If you are storing Unix timestamps in a column or struct, confirm the underlying type is at least 64-bit — and if you have any doubt, switch to milliseconds, which already overflows a 32-bit signed integer and forced the upgrade decades ago.

All parsing, formatting, and relative-time arithmetic runs in your browser as a small pure function (under 2 KB). The relative-time row ticks once a second via `setInterval` while the page is open. Nothing leaves your device.