Unix Time, Timezones, and the Leap Second Problem
A timestamp comes out exactly one hour off, or a date that should read the 14th shows up as the 15th depending on which timezone is doing the reading, and it's tempting to assume the code has a bug somewhere. Often it doesn't. Every Unix timestamp is a single number: seconds since midnight UTC on January 1, 1970. It's a clean idea that runs into a genuinely messy problem the moment it meets the Earth's actual, slightly irregular rotation.
Why 1970, specifically
The Unix epoch, January 1, 1970. Wasn't chosen for any deep technical reason; it was simply a convenient round date close to when Unix itself was under development at Bell Labs in the early 1970s, and it stuck as the reference point every timestamp since has counted from. A timestamp is just an integer count of seconds from that instant, which makes date arithmetic trivial for computers (subtract two integers) even though it's the opposite of intuitive for humans.
That single-number design is also why a timestamp is never "wrong" on its own, even when the date or time displayed from it clearly is. A Unix timestamp carries no timezone information at all; it's the code converting it into a human-readable date that decides what offset to apply. An hour-off result is almost always a sign that the conversion picked the wrong offset, usually around a daylight saving change, not that the underlying number is broken.
The overflow problem hiding in older systems
Older systems store that integer as a signed 32-bit number, which can only count up to 2,147,483,647 before it overflows and wraps around to a negative number. A date interpreted as December 1901 instead of the intended date. That overflow happens at exactly 03:14:07 UTC on January 19, 2038, a date engineers refer to as the Y2038 problem. Most modern systems have already moved to 64-bit timestamps, which push the same overflow out roughly 292 billion years, but embedded and legacy systems built on 32-bit time remain a real, documented risk for that date.
Unix time quietly ignores leap seconds
Earth's rotation isn't perfectly steady. It slows down unpredictably by fractions of a second over time. So international timekeepers periodically insert a leap second into UTC to keep clock time aligned with the planet's actual rotation. Unix time, by design, does not count leap seconds at all: every day is defined as exactly 86,400 seconds, full stop, which means Unix time and UTC quietly drift apart by exactly the number of leap seconds ever inserted (27, as of the last one added in 2016) unless something intervenes. Systems that need to stay synced handle this with a "leap smear". Spreading the extra second gradually over many hours around midnight rather than inserting a jarring repeated second. An approach popularized by Google and adopted widely because a sudden 61-second minute breaks a surprising amount of software that assumes time only moves forward.
Leap seconds are being retired
In November 2022, the world's metrology authorities (the CGPM, which oversees international time and measurement standards) voted to stop inserting leap seconds altogether by 2035, specifically because they'd become a persistent source of software bugs at exactly the scale. Financial trading systems, satellite navigation, telecoms. Where a one-second discrepancy is expensive to get wrong. Timezones remain the more everyday headache: the IANA time zone database that underlies almost all timestamp-conversion software is updated several times a year as individual countries adjust their own daylight saving rules, which is why a timezone library that converted correctly a few years ago can quietly start producing wrong answers for a specific country without any code changing at all.
What to actually do about it
If the goal is tracking down a timestamp that's exactly one hour off, check which timezone and daylight saving offset got applied at conversion, not the stored number itself; the timestamp is timezone-agnostic, and the bug is almost always in the code or setting that turns it into a displayed date. If the goal is handling leap seconds in a system that can't tolerate a repeated second, use a leap smear rather than inserting the second directly, the way large-scale systems already do. If the goal is making sure old code won't break in 2038, confirm timestamps are stored as 64-bit integers rather than 32-bit, especially in older or embedded systems where that assumption is easy to miss.
Convert between Unix timestamps and human-readable dates across timezones with the timestamp converter.