Unix Timestamp — Epoch Time

What Is a Unix Timestamp?

A Unix timestamp, also called epoch time or POSIX time, is a way of representing a specific moment in time as a single integer. It counts the number of seconds that have elapsed since the Unix epoch, which is defined as midnight (00:00:00) on January 1, 1970, Coordinated Universal Time (UTC). At that exact moment the counter was zero, and it has been incrementing by one for every second since.

The concept originated at Bell Labs in the early 1970s when Ken Thompson and Dennis Ritchie were building the Unix operating system. They needed a simple, compact way to store and compare dates and times. Rather than encoding years, months, days, hours, minutes, and seconds separately, they chose a single running counter. This decision proved to be one of the most enduring design choices in computing history, and the Unix timestamp is now the de facto standard for time representation in operating systems, programming languages, databases, file systems, and network protocols around the world.

The choice of January 1, 1970 as the epoch was pragmatic. The designers needed a date recent enough that the resulting numbers would stay small on the 32-bit hardware of the era, but early enough to represent dates in the recent past. 1970 was roughly the year Unix development began, making it a natural starting point. There is nothing inherently special about the date itself; it is simply a shared convention that every system agrees upon.

One of the most important properties of Unix time is its timezone independence. Because the epoch is defined in UTC, a Unix timestamp always refers to the same absolute instant regardless of where in the world it is interpreted. The value 1700000000, for example, corresponds to November 14, 2023 at 22:13:20 UTC everywhere. Local time zones and daylight saving offsets are applied when converting the timestamp to a human-readable string, but the underlying number is universal. This property makes Unix timestamps ideal for storing event times in databases, coordinating API calls across distributed systems, and logging events in applications that span multiple geographic regions.

Unix timestamps are used extensively in modern software. Databases such as PostgreSQL, MySQL, and SQLite all support timestamp columns stored as integers. Web APIs commonly pass dates as Unix timestamps in JSON payloads because integers are compact, unambiguous, and trivial to parse. File systems record creation and modification times as epoch seconds. Caching layers like Redis and Memcached use timestamps for expiration. Build systems, CI/CD pipelines, and log aggregators all rely on epoch seconds for ordering events.

How Unix Time Works

At its core, Unix time is simply a count of seconds. Each tick of the clock adds one to the counter. There are exactly 86,400 seconds in a Unix day (24 hours multiplied by 60 minutes multiplied by 60 seconds), and Unix time makes no exceptions to this rule. This flat, monotonic representation is what makes it so much simpler than calendar dates.

Calendar dates are complicated because months have different lengths, leap years add an extra day to February, and time zones shift the boundary between one date and the next. Converting "March 15, 2024 at 14:30 in Eastern Daylight Time" to a comparable value requires knowing the UTC offset, whether daylight saving is in effect, and how many days have elapsed since some reference point. A Unix timestamp collapses all of that complexity into a single integer.

POSIX, the standard that formalizes Unix time, deliberately ignores leap seconds. The international timekeeping community occasionally inserts a leap second to keep atomic clocks aligned with Earth's slightly irregular rotation. Under strict physical reckoning, some minutes have contained 61 seconds. POSIX, however, defines every minute as exactly 60 seconds and every day as exactly 86,400 seconds. When a leap second occurs, Unix systems typically either repeat a second or smear the extra second across a longer window. This means that Unix time is not a perfect count of SI seconds elapsed since the epoch, but it is a count of "POSIX seconds," which are defined to make the math simple and predictable.

Negative Unix timestamps represent moments before the epoch. The timestamp -86400 corresponds to December 31, 1969 at 00:00:00 UTC, exactly one day before the epoch. This allows Unix time to express historical dates, though in practice many systems treat the timestamp as unsigned or restrict it to non-negative values.

The Year 2038 Problem

The Year 2038 problem, often abbreviated as Y2K38, is the most significant looming issue in Unix timekeeping. It stems from the fact that many systems store the Unix timestamp as a signed 32-bit integer. A signed 32-bit integer can hold values from negative 2,147,483,648 to positive 2,147,483,647. The maximum positive value, 2,147,483,647, corresponds to January 19, 2038 at 03:14:07 UTC.

One second later, a 32-bit signed counter would overflow. Instead of incrementing to 2,147,483,648, the value wraps around to negative 2,147,483,648, which the system interprets as December 13, 1901 at 20:45:52 UTC. Any software or hardware that relies on a 32-bit timestamp will suddenly believe it has traveled more than 136 years into the past. Scheduled tasks will misfire, certificate expiration checks will produce wrong results, file modification times will appear nonsensical, and database queries involving date comparisons will return incorrect data.

The affected systems are more numerous than many people realize. Embedded devices such as industrial controllers, automotive ECUs, medical equipment, ATMs, and IoT sensors frequently use 32-bit processors with 32-bit time libraries. Legacy database schemas store timestamps in 32-bit integer columns. Older file systems like ext2 and FAT use 32-bit timestamps for file metadata. Network protocols that were designed decades ago encode time in 32-bit fields. Even some modern software written in C or C++ still calls the traditional time() function, which historically returned a 32-bit time_t on many platforms.

The solution is straightforward in principle: use 64-bit integers for time storage. A signed 64-bit timestamp can represent dates up to approximately 292 billion years in the future, which is well beyond any practical need. Most modern 64-bit operating systems, including recent versions of Linux, macOS, and Windows, have already migrated their internal time representations to 64-bit. The Linux kernel completed this transition for 32-bit ARM architectures in version 5.6. Programming languages like Python, Java, and Go use 64-bit time natively. The challenge lies in the long tail of embedded systems, legacy code, and binary data formats that still assume 32-bit time and may be difficult or impossible to update.

Unix Timestamps in Programming

Every major programming language provides built-in facilities for working with Unix timestamps. In JavaScript, Date.now() returns the current time as a millisecond timestamp, and dividing by 1000 and flooring the result gives the Unix timestamp in seconds. The Date constructor accepts a millisecond timestamp and produces a date object that can be formatted for display. This is one of the most common sources of bugs when working across languages: JavaScript uses milliseconds by default, while most other languages and systems use seconds.

In Python, the time module provides time.time(), which returns the current Unix timestamp as a floating-point number. The integer part is the seconds and the fractional part gives sub-second precision. The datetime module offers datetime.fromtimestamp() and datetime.utcfromtimestamp() for converting timestamps to datetime objects. Python 3.3 and later also provide datetime.timestamp() for the reverse conversion.

PHP offers the time() function, which returns the current Unix timestamp as an integer in seconds. The strtotime() function parses a human-readable date string and returns the corresponding timestamp. The date() function formats a timestamp into a readable string. PHP's date functions are timezone-aware and will apply the server's configured timezone unless explicitly told otherwise.

In SQL, the syntax varies by database engine. PostgreSQL provides EXTRACT(EPOCH FROM timestamp) to convert a timestamp column to Unix time, and TO_TIMESTAMP(epoch) to go the other direction. MySQL offers UNIX_TIMESTAMP() and FROM_UNIXTIME(). SQLite does not have a dedicated timestamp type but stores dates as text, real, or integer, and provides the strftime('%s', datetime) function to extract epoch seconds.

The most common gotcha across all languages is the seconds-versus-milliseconds confusion. A 10-digit number is a seconds-based Unix timestamp. A 13-digit number is almost certainly a millisecond timestamp as used by JavaScript, Java, and some logging frameworks. Accidentally interpreting a millisecond timestamp as seconds will produce a date tens of thousands of years in the future. Conversely, treating a seconds timestamp as milliseconds yields a date in January 1970, just hours after the epoch. Always check the magnitude of a timestamp before converting it.