A meeting scheduled for "3 PM" between someone in New York and someone in London sounds unambiguous until you actually try to coordinate it, and discover that the simple offset most people carry in their heads — "London is 5 hours ahead" — is only true for part of the year, and only one specific part at that.
Why the offset between two cities isn't actually fixed
The time difference between two locations depends not just on their base timezone offsets from UTC, but on whether either location is currently observing daylight saving time, and if so, exactly when their specific DST transition dates fall in the calendar. Two locations that both observe DST, but on different transition dates, will have their relative offset shift not just twice a year (when each individually transitions) but potentially have a period where the effective gap between them differs from both their "standard" and their "both-in-DST" offset, depending on the specific weeks each side transitions.
This is exactly why "New York is 5 hours behind London" is only reliably true during the specific stretch of the year when both locations happen to be in the same DST state relative to each other — during the weeks surrounding each side's individual transition, the actual gap temporarily differs from that simple 5-hour figure, sometimes by an hour in either direction depending on which side has transitioned and which hasn't yet.
The southern hemisphere makes this even less intuitive
Daylight saving time transitions are tied to each hemisphere's respective spring and fall, which means southern hemisphere locations that observe DST do so on essentially opposite months from northern hemisphere locations — a southern hemisphere country's "spring forward" transition happens around what's northern hemisphere autumn, and vice versa. Scheduling a meeting between a northern and southern hemisphere location adds an extra layer of complexity, since the offset between the two doesn't follow the same simple, predictable pattern that scheduling within a single hemisphere might roughly approximate — the two locations' DST calendars are essentially inverted relative to each other.
Why "just add or subtract hours" eventually produces a wrong meeting time
Manually calculating a meeting time by mentally adding or subtracting a fixed number of hours works exactly as long as neither location has recently transitioned, or is about to transition, relative to when the offset was originally calculated. A meeting scheduled months in advance, using an offset that was accurate at the time of scheduling, can end up an hour off by the time the meeting actually occurs, if a DST transition happened to fall somewhere in between the scheduling and the actual meeting date on either side. This is a well-known and genuinely common source of missed or mistimed international meetings, and it happens specifically because the underlying offset assumption silently became stale between when it was calculated and when it was actually used.
Why calendar software that handles timezones correctly is more reliable than manual math
A properly built calendar application stores a meeting's scheduled time along with an explicit timezone reference (not a fixed UTC offset), and correctly recalculates the equivalent local time for each participant's own timezone setting at the moment the calendar is actually viewed — automatically accounting for whatever DST rules apply to each participant's location on the actual meeting date, rather than relying on an offset that was manually calculated once and never revisited. This is exactly the same underlying principle covered in more depth in an earlier post on this blog about timezone bugs in software more broadly: storing a proper timezone reference rather than a fixed offset avoids this entire category of error.
Finding a genuinely good overlapping meeting window
Beyond just correctly converting a single specific time, scheduling an international meeting well also means finding a window that falls within reasonable working hours for every participant — not just technically "not the middle of the night" for one side while comfortably mid-morning for the other. A meeting time that's technically valid but falls at 6 AM or 11 PM local time for one participant is a poor outcome even if the actual time conversion math is perfectly correct, so a genuinely useful scheduling approach looks at both parties' full working-hours overlap, not just a single converted time point.
Finding that overlap directly
Our meeting time planner lays out a full 24-hour comparison between two timezones side by side, highlighting the hours that fall within typical working hours for both, and reads live from your browser's own timezone database so DST transitions on either side are automatically reflected without any manual offset arithmetic — sidestepping exactly the stale-offset problem described above.