Timezone bugs have a well-earned reputation as some of the most quietly annoying problems in software — code that works perfectly in testing, passes review, ships to production, and then breaks for a specific subset of users at a specific time of year in a way nobody anticipated. Almost every recurring timezone bug traces back to one of a small number of well-understood misunderstandings, which makes them worth actually learning rather than re-discovering the hard way each time.
UTC offset is not the same thing as a timezone
This is the single most common source of confusion. A UTC offset (like UTC-5) tells you how far a given moment's local time is from Coordinated Universal Time, but a timezone is a named region with rules about when and whether that offset changes throughout the year for daylight saving time. Treating "UTC-5" as equivalent to "Eastern Time" works for exactly half the year and silently breaks for the other half, because Eastern Time is UTC-5 during standard time and UTC-4 during daylight saving time — the offset itself isn't a stable identity, only the named timezone with its full set of rules actually captures that.
Storing a fixed offset instead of a proper timezone identifier is a very common and very quiet bug, because it works flawlessly in testing (which usually happens to fall within a single DST period) and then breaks specifically for events or calculations that straddle a DST transition, which might not surface for months after the code shipped.
Daylight saving time doesn't happen everywhere, or on the same date
A significant share of the world doesn't observe daylight saving time at all, and among the regions that do, the specific transition dates vary — the US and much of Europe don't even switch on the same weekend as each other, let alone matching every other DST-observing region globally. Code that assumes a single global "spring forward, fall back" date, or assumes every user experiences DST the same way, breaks for a substantial share of any genuinely international user base, and the specific breakage (an event showing up an hour off, a recurring reminder firing at the wrong time) is often subtle enough to go unnoticed for a long time.
The DST transition itself creates genuinely ambiguous or nonexistent times
During a "spring forward" transition, an entire hour of local time is skipped — 2:00 AM might jump directly to 3:00 AM, meaning a local time like 2:30 AM genuinely never occurred that day in that timezone. During a "fall back" transition, the reverse happens: an hour of local time occurs twice, meaning a local time like 1:30 AM is genuinely ambiguous, since it could refer to either occurrence without additional context about which side of the transition it falls on. Code that schedules a recurring event for a specific local time without accounting for this can end up either skipping the event entirely on the spring-forward day, or firing it twice on the fall-back day, in a way that only reproduces once a year on the exact transition date.
Storing local time instead of UTC creates a moving target
A widely recommended practice, precisely because of the issues above, is to store timestamps internally as UTC and only convert to a specific local timezone at the moment of display, rather than storing a local time directly. Storing local time bakes in an assumption about which timezone and which DST rules applied at that specific moment, and if timezone rules ever change (governments do periodically adjust DST rules, sometimes with limited advance notice), historical timestamps stored as local time can become ambiguous or simply wrong after the fact, while UTC timestamps remain unambiguous and stable regardless of any later rule change.
Why "just add or subtract hours" almost always breaks eventually
Manually adding or subtracting a fixed number of hours to convert between timezones works exactly as long as neither timezone is currently observing a different DST state than when the offset was hardcoded, and exactly as long as no DST transition falls within whatever date range the code is handling. Both of those conditions eventually stop holding true, usually at an inconvenient moment, which is why relying on a proper timezone-aware date library — one that has the full historical and future DST rule tables built in, rather than treating timezones as fixed offsets — reliably produces more correct results than manual offset arithmetic, even though the manual approach looks simpler and often "works" in casual testing.
A quick reference for coordinating across timezones
If you just need to sanity-check what a specific moment looks like across a couple of timezones, or find a genuinely convenient overlapping window for scheduling a meeting with people in different regions, our meeting time planner lays out a full 24-hour comparison between two zones with typical working hours highlighted, reading live from your browser's own timezone database so daylight saving shifts are reflected automatically without any manual offset math on your part.
The underlying lesson
Almost every one of these bugs comes from treating a timezone as a simple, fixed number when it's actually a set of rules that change over the course of a year and sometimes change permanently over the course of years. Code that respects that complexity — using proper timezone identifiers, storing UTC internally, and leaning on a real timezone-aware library rather than manual offset math — sidesteps the entire category of bug rather than fixing individual symptoms of it one at a time as they surface.