Complete Technical Guide to Unix Timestamps, UTC, and Time Handling
A Unix timestamp (also known as POSIX time or Epoch seconds) represents time as an integer count of seconds elapsed since 00:00:00 UTC on Thursday, January 1, 1970. Because it is completely agnostic of geographical boundaries, time zones, and daylight saving time (DST) shifts, it serves as the foundational chronological standard for databases (MySQL, PostgreSQL, MongoDB, Redis), distributed microservices, REST APIs, and authentication tokens (JWT).
Storing dates as Unix integers in database indexes allows for ultra-fast range queries, sorting, and expiration calculations without incurring the CPU overhead of string date parsing. It also guarantees that two servers located in Tokyo and New York will agree on the exact absolute moment an event occurred regardless of local clock configurations.
Coordinated Universal Time (UTC) vs. Local Timezone
A common misconception among developers is that timestamps store timezone information. In reality, a Unix timestamp represents a single, universal point on the timeline. The difference between UTC and Local Time is strictly an offset applied at the moment of presentation:
- UTC (Coordinated Universal Time): The zero-offset time standard (GMT) against which all world clocks are synchronized. It never shifts for summer or winter daylight saving transitions.
- Local Time: The human-readable date and time computed by taking UTC and adding or subtracting the local geographical UTC offset (e.g., UTC+1 for Madrid/Paris in winter, UTC+2 in summer, UTC-5 for New York in winter).
Because the offset changes dynamically throughout the year depending on regional legislation, converting a timestamp to local time requires consulting the host operating system's IANA Time Zone Database (tzdata).
Why POSIX Time Ignores Leap Seconds
To ensure mathematical predictability, the POSIX Unix time standard defines every day as containing exactly 86,400 seconds (24 × 60 × 60). When the International Earth Rotation and Reference Systems Service (IERS) inserts a leap second to compensate for Earth's irregular rotational deceleration, Unix clocks accommodate the extra second by repeating second 86,400 or using Google-style "leap smearing" (gradually slowing the clock over 24 hours). This design guarantees that subtracting two timestamps divided by 86,400 always yields the exact number of standard calendar days elapsed.
Practical Example
JWT "exp" Claim: 1772150400
UTC: Fri, 27 Feb 2026 00:00:00 GMT | ISO 8601: 2026-02-27T00:00:00Z
Security gateways compare the current epoch time with the "exp" claim value to determine whether an API request authorization token is valid or expired.
Cache-Control max-age: 86400 | Current Epoch: 1772150400
Expires Header: Sat, 28 Feb 2026 00:00:00 GMT (Epoch: 1772236800)
Adding 86,400 seconds (exactly 1 day) calculates future expiration timestamps for browser caching layers and CDN edge servers.