Unix Timestamp Converter

A Unix timestamp counts elapsed time since 1970-01-01T00:00:00Z, but the unit is not part of the value, and that ambiguity causes more bugs than anything else in date handling. Unix tooling, JWT claims, database `TIMESTAMP` columns and most APIs use seconds. JavaScript's `Date.now()`, Java's `System.currentTimeMillis()` and many logging systems use milliseconds.

Digit count is a reliable check for the current era. A 10-digit value is seconds and lands in the present. A 13-digit value is milliseconds. If a date comes out in 1970, you passed milliseconds to something expecting seconds - divide by 1000. If it comes out around the year 55,000, you did the reverse.

Microseconds (16 digits) appear in Postgres internals and some tracing systems, and nanoseconds (19 digits) in Go's `time.UnixNano()` and Prometheus. Both are worth recognising, because a nanosecond timestamp exceeds JavaScript's safe integer range and will lose precision if parsed as a plain number.

A Unix timestamp is an absolute instant. It carries no timezone because it does not need one - the same value refers to the same moment everywhere on earth. Timezones enter only when you format that instant for a person to read, and that is a presentation concern rather than a storage one.

This is why the standard advice is to store timestamps in UTC and convert only at the display layer. Storing local times means every read has to know which zone was intended, and any daylight-saving transition makes some local times ambiguous or nonexistent. The hour that repeats when clocks go back genuinely maps two different instants to one local time.

The `Z` suffix in ISO 8601 means UTC specifically, and an offset like `+02:00` means a fixed displacement from it. Neither identifies a timezone: `+02:00` could be Central European Summer Time or South Africa Standard Time, and only one of them observes daylight saving. When you need to store a future local time - a recurring calendar appointment - you need the IANA zone name like `Europe/Oslo`, because the offset itself may change before the event arrives.

A signed 32-bit integer holding seconds overflows on 19 January 2038 at 03:14:07 UTC, wrapping to December 1901. This is a real deadline for embedded systems, older C code and any database column defined as a 32-bit int. Modern systems use 64-bit values and are safe for roughly 292 billion years, but legacy code with `time_t` as a 32-bit type still exists in deployed hardware.

Two other boundaries are worth knowing. JavaScript's `Date` is limited to ±8,640,000,000,000,000 milliseconds from the epoch - about ±273,000 years - and anything beyond becomes an Invalid Date. And integers above 2^53 lose precision as IEEE-754 doubles, which is exactly why nanosecond timestamps must be handled as strings or BigInt in JavaScript rather than as numbers.

Negative timestamps represent dates before 1970 and are valid, though support is inconsistent. Some systems reject them, some treat them as unsigned and produce dates in 2106, and some handle them correctly. If you work with historical dates, test this rather than assuming.

Unix time is defined as counting seconds since the epoch excluding leap seconds, which means it does not track true elapsed physical time. When a leap second is inserted, the Unix clock either repeats a value or is stepped, depending on the platform's approach.

The practical implication is that a Unix timestamp is not a reliable measure of duration across a leap second, and that timestamps are not strictly monotonic - the same value can occur twice. Google and others avoid the discontinuity with leap smearing, spreading the adjustment across a day so no clock ever jumps.

For almost all application code this does not matter. It matters if you are measuring durations with sub-second precision across a leap second boundary, or if you rely on timestamps being unique and strictly increasing. In the second case use a monotonic clock for durations, and a proper sequence or UUID v7 for ordering.