Every developer eventually encounters a number like 1719878400 in a database column, a log file, or an API response and wonders what it means. That number is a Unix timestamp: the number of seconds that have elapsed since midnight UTC on January 1, 1970. It is one of the oldest and most widely used conventions in computing, and understanding it makes debugging time-related issues significantly faster.
Why January 1, 1970?
The Unix epoch: midnight UTC on January 1, 1970: was chosen as the reference point when Unix was being developed in the late 1960s and early 1970s. The choice was somewhat arbitrary, though it was chosen to be recent enough that 32-bit integers could represent a useful range of past and future dates. The specific date had no particular significance beyond being a round number close to when the system was designed.
Seconds vs milliseconds: an important distinction
Original Unix timestamps count seconds. Most Unix system calls, command-line tools, and POSIX-compliant APIs use seconds. However, JavaScript's Date.now() returns milliseconds since the epoch: a number approximately 1,000 times larger. Many modern APIs and databases (particularly NoSQL databases and JavaScript-heavy stacks) use milliseconds for finer precision. The difference between 1719878400 (seconds: year 2024) and 1719878400000 (milliseconds: a date in 1970 plus a few milliseconds) is the source of a common class of time parsing bugs.
Converting a Unix timestamp
In JavaScript: new Date(1719878400 * 1000) converts a seconds timestamp to a Date object (note the multiplication by 1000 to convert to milliseconds). In Python: datetime.fromtimestamp(1719878400) converts a seconds timestamp to a datetime object in local time, while datetime.utcfromtimestamp(1719878400) gives UTC. In SQL (PostgreSQL): to_timestamp(1719878400) converts to a timestamp with time zone.
The year 2038 problem
32-bit signed integers can represent a maximum value of 2,147,483,647. The Unix timestamp 2,147,483,647 corresponds to January 19, 2038, at 03:14:07 UTC. Systems that store timestamps as 32-bit signed integers will overflow at this point: rolling over to a large negative number that represents a date in 1901. This is sometimes called Y2K38. Modern 64-bit systems and languages are not affected because 64-bit integers can represent dates billions of years in the future, but embedded systems and legacy code that uses 32-bit time_t types remain at risk.
Timestamps in different contexts
- •Unix system calls: seconds since epoch, 32-bit or 64-bit depending on the platform.
- •JavaScript Date: milliseconds since epoch, 64-bit floating-point.
- •Python datetime: microseconds precision available via the datetime.timestamp() method which returns a float.
- •PostgreSQL: stores timestamps as microseconds since January 1, 2000 (a different epoch), but displays and accepts Unix timestamps via to_timestamp().
- •Git commits: seconds since epoch stored in the commit metadata.
- •JWT (JSON Web Tokens): the iat (issued at) and exp (expiry) claims are seconds since epoch.
- •HTTP headers: the Date and Last-Modified headers use RFC 7231 date format, not Unix timestamps: but many caching systems convert to timestamps internally.
AlteredIdea's Timestamp Converter converts Unix timestamps (seconds or milliseconds) to human-readable dates and back, in any timezone. Paste a timestamp from a log or API response and instantly see what time it represents.