A Unix timestamp (also called epoch time or POSIX time) is a single integer representing the number of seconds that have elapsed since 00:00:00 UTC on January 1, 1970 — the Unix epoch. This date was chosen somewhat arbitrarily by early Unix developers as a convenient reference point during the system's development at Bell Labs.
The Unix timestamp 0 corresponds to January 1, 1970 at midnight UTC. A timestamp of 1 is one second later, and so on. As of mid-2025, timestamps are in the range of 1750000000 — roughly 55 years worth of seconds since the epoch. The integer is stored as a 32-bit signed value in many legacy systems, which will overflow on January 19, 2038 (the Year 2038 problem).
Because it's a single number, a Unix timestamp is unambiguous, compact, and easy to store, compare, and transmit. Two timestamps can be subtracted to calculate duration. A larger timestamp always represents a later point in time, regardless of timezone or locale.
Converting a Unix timestamp to a human-readable date requires knowing the target timezone, since the timestamp itself is always in UTC. Every programming language provides built-in functions for this conversion:
new Date(1750000000 * 1000).toLocaleString() — multiply by 1000 because JavaScript uses milliseconds.date('Y-m-d H:i:s', 1750000000) — set the default timezone with date_default_timezone_set() first.datetime.fromtimestamp(1750000000, tz=timezone.utc) from the datetime module.date -d @1750000000 on Linux or date -r 1750000000 on macOS.Reverse conversion — going from a date to a timestamp — is equally straightforward. This is useful when you need to store dates in databases, set cache expiration times, or calculate time differences. Most database systems (MySQL, PostgreSQL, SQLite) include native functions like UNIX_TIMESTAMP() or EXTRACT(EPOCH FROM ...).
Unix timestamps are inherently timezone-free — they always represent a moment in UTC. Timezone information only matters when converting to or from human-readable format. This separation is one of the key advantages: you can store a timestamp in a database and let each user's application convert it to their local time.
Common pitfalls with timestamps and timezones include:
On January 19, 2038 at 03:14:07 UTC, 32-bit signed Unix timestamps will reach their maximum value of 2,147,483,647 and overflow to -2,147,483,648, which represents December 13, 1901. This affects any system using a signed 32-bit integer to store timestamps — older Linux kernels, embedded devices, legacy database schemas, and many IoT devices.
Modern 64-bit systems are unaffected because 64-bit signed integers can represent timestamps up to the year 292,277,026,596 — effectively forever. The fix is straightforward for systems that can be rebuilt: switch to 64-bit time types (time_t on 64-bit platforms). The real risk is in embedded systems and legacy devices that cannot be updated.
Unix timestamps are everywhere in computing. They power cache expiration headers, API authentication, database indexing, log correlation, and build systems. When you see a Last-Modified HTTP header, a JWT expiration claim, or a git commit timestamp, you're looking at epoch time.
Their simplicity makes them ideal for machine-to-machine communication. No parsing is needed to compare two timestamps — just integer comparison. No ambiguity about formats (MM/DD vs DD/MM). No timezone guessing required. That's why they remain the standard for programmatic time handling more than 50 years after the epoch began.