Unix time, also known as Epoch time or POSIX time, is a system for tracking time as a single continuously incrementing number: the count of seconds that have elapsed since 00:00:00 UTC on January 1, 1970. This specific moment—the "Unix epoch"—was chosen somewhat arbitrarily by the early Unix developers at Bell Labs. The original Unix operating system, developed by Ken Thompson and Dennis Ritchie in the late 1960s, needed a simple way to represent time, and a single integer counting seconds from a fixed point was the most straightforward approach for the limited hardware of the era.

The beauty of Unix timestamps lies in their simplicity and universality. A Unix timestamp is a single number that means the same thing everywhere in the world, regardless of timezone, daylight saving time, calendar system, or locale settings. The timestamp 1700000000 represents November 14, 2023 at 22:13:20 UTC whether you are in Tokyo, London, or New York. This timezone independence makes Unix timestamps ideal for storing time in databases, communicating time between systems, and performing time arithmetic. Subtracting two timestamps gives the duration between events in seconds—no timezone conversion, no calendar math, no daylight saving time complications.

The original Unix time implementation used a 32-bit signed integer, which can represent values from approximately -2.1 billion to +2.1 billion. This creates the infamous "Year 2038 problem" (sometimes called the "Unix Millennium Bug" or Y2K38): at 03:14:07 UTC on January 19, 2038, a 32-bit signed Unix timestamp will overflow, wrapping from its maximum positive value to its maximum negative value. Systems still using 32-bit timestamps will interpret dates after this moment as dates in December 1901. The problem is analogous to Y2K but potentially more impactful because Unix timestamps are deeply embedded in operating system kernels, file systems, network protocols, and embedded devices. The solution—using 64-bit integers—has been widely adopted in modern systems and extends the range to approximately 292 billion years in either direction, effectively eliminating the overflow concern.

JavaScript introduced a notable variation by using millisecond-precision timestamps. The Date.now() function and Date object internally use milliseconds since the epoch rather than seconds, producing 13-digit numbers like 1700000000000 instead of 10-digit numbers. This higher precision is useful for performance measurement, animation timing, and distinguishing events that occur within the same second. Other languages and systems vary: Python's time.time() returns seconds as a floating-point number, Java's System.currentTimeMillis() uses milliseconds, and databases may use seconds, milliseconds, microseconds, or even nanoseconds depending on the platform.

Leap seconds add a subtle complication to Unix time. The Earth's rotation is gradually slowing, so astronomical time (UT1) slowly diverges from atomic clock time (UTC). To keep them aligned, the International Earth Rotation and Reference Systems Service occasionally inserts a "leap second"—a 61st second in a minute. Unix time, however, does not account for leap seconds; it pretends every day has exactly 86,400 seconds. During a leap second, the Unix timestamp essentially repeats a second or, depending on implementation, uses techniques like Google's "leap smear" to distribute the extra second across a longer period. This means Unix timestamps are not a perfectly continuous count of SI seconds, but the discrepancy is negligible for virtually all practical applications.