Unix Timestamp

Why Unix time starts at January 1, 1970

The Unix epoch — the reference point of zero from which Unix timestamps are counted — is 00:00:00 UTC on Thursday, 1 January 1970. This date was chosen by the developers of the early Unix operating system at Bell Labs in the early 1970s. They needed a date recent enough to be practical for their systems, and 1970 fit neatly.

The choice was somewhat arbitrary — similar to how many calendars use a historically significant or convenient date as year zero. The Y2K problem (two-digit year representation) has a loose analogue in Unix time: 32-bit systems can store timestamps only up to 2,147,483,647 seconds (maximum positive value of a signed 32-bit integer), which corresponds to 03:14:07 UTC on 19 January 2038. This "Year 2038 problem" (Y2K38) will cause overflow on systems still using 32-bit Unix timestamps on that date. Modern 64-bit systems can represent dates billions of years in the future.

Seconds vs milliseconds — why both exist and how to tell them apart

Unix timestamps are traditionally measured in seconds. This is sufficient for most scheduling, logging, and database use cases where second-level precision is adequate. Most Unix shell commands (date +%s), most database timestamp fields, and most API standards use second-precision timestamps.

JavaScript's Date.now() and the majority of JavaScript date APIs return timestamps in milliseconds (1/1000 of a second). This is because JavaScript was designed for web applications that need to measure animation frames, user interaction timing, and performance benchmarks — all of which require sub-second precision. Java's System.currentTimeMillis() also returns milliseconds.

Distinguishing them visually: a Unix timestamp in seconds has 10 digits (until 2286); a millisecond timestamp has 13 digits. This tool autodetects the unit based on the number of digits. A common bug is passing a millisecond timestamp to an API that expects seconds — producing dates thousands of years in the future. Always verify the expected unit from the API documentation.

Daylight Saving Time and why timestamp conversion is tricky

Daylight Saving Time (DST) is the practice of advancing clocks by one hour during summer months to extend evening daylight. It is observed in roughly 70 countries, though with different start/end dates. The US, EU, Australia, and most of the Americas observe DST; most of Asia, Africa, and parts of South America do not.

Unix timestamps are always in UTC (Coordinated Universal Time) and are not affected by DST — a single timestamp always refers to the same absolute moment in time. The complexity comes when converting to a local timezone for display. During a DST transition, clocks "spring forward" (skipping an hour) or "fall back" (repeating an hour).

This means that on DST change nights, some local clock times are ambiguous (they occur twice during the fall-back transition) or nonexistent (they are skipped during the spring-forward transition). The browser's Intl.DateTimeFormat API, which this tool uses, handles DST correctly by using the IANA timezone database — the same database used by most operating systems. When working across timezones in code, always store timestamps in UTC and convert to local time only for display.