Scheduling Across Time Zones: Why Your Meeting Moved an Hour
Why standing meetings between the US and Europe slide an hour every March, and the date-aware conversion habit that keeps cross-zone invites honest
A meeting planner for time zones needs three inputs, not two: both places and the date. The hour gap between two cities is not a fixed fact — it is a fact about a particular day, because zones that observe daylight saving change their UTC offset twice a year, and the world does not change together. That is the entire design of the time zone converter: give it a date, a time and two zones, and it returns the destination wall-clock time, a day-shift flag (is it already tomorrow there?), and the true UTC offset each zone runs on that date, resolved fresh rather than assumed.
If you are here because a standing meeting just moved an hour, that is the same fact seen from the other side. A recurring event is pinned to one zone — normally the organiser's. When that zone enters or leaves daylight saving and yours does not, or has not yet, your local rendering of the identical instant moves by an hour with nobody touching the invite. Twice a year the United States and Europe run mismatched daylight-saving calendars for a stretch of days, and during those windows every meeting between them slides. Here is exactly when, by how much, in which direction — and the habit that stops it costing you a call.
The gap between two cities is one line of arithmetic
destination clock = source clock + (destination UTC offset − source UTC offset), with both offsets resolved for the specific date
Everything difficult lives in that final clause. New York is UTC−5 in January but UTC−4 in July; London is +0 in winter and +1 in summer; Nairobi is +3 in every season. Noon in New York therefore reaches Nairobi at 20:00 in January, when the gap is 3 − (−5) = 8 hours, but at 19:00 in July, when it is 3 − (−4) = 7. Nairobi changed nothing. New York moved its clocks and dragged the difference along.
That is also why the converter asks for cities, not offsets. A name like America/New_York is the stable identifier in the IANA Time Zone Database — the rulebook every operating system and calendar application resolves against — while the offset is a per-date lookup. The result panel prints both resolved offsets, so you can see which daylight-saving state produced your answer instead of trusting a bare number.
The March window: two weeks of a four-hour Atlantic
The United States springs forward in mid-March; Europe follows at the end of March. For roughly two weeks in between, New York–London runs an hour closer than either side expects:
| Stretch of the year | New York | London | Gap | 10:00 in New York is |
|---|---|---|---|---|
| Winter — both on standard time | UTC−5 | UTC+0 | 0 − (−5) = 5 h | 15:00 in London |
| Mid- to late March — US shifted alone | UTC−4 | UTC+0 | 0 − (−4) = 4 h | 14:00 in London |
| Summer — both on daylight time | UTC−4 | UTC+1 | 1 − (−4) = 5 h | 15:00 in London |
The middle row is the answer to "why did my meeting time change." A 10:00 New York standing call that London knows as a 15:00 fixture turns up at 14:00 for those two weeks, then snaps back. Who experiences the move depends on who owns the event: were the organiser in London instead, New Yorkers would watch their 10:00 become 11:00 while London's clock stayed put — their own clocks jumped forward, so the unchanged instant reads an hour later.
The staggering repeats in mirror image each autumn, when Europe returns to standard time before the United States does — the pairing spends a second window at 0 − (−4) = 4 hours before both settle back to five.
Which pairings drift — and which never do
| Pairing | Example | Over a year |
|---|---|---|
| Same daylight-saving calendar | New York ↔ Chicago | Both move on the same nights; the gap never changes |
| Both shift, different calendars | New York ↔ London | Slides an hour through the March window and again in autumn, then returns |
| Only one side shifts | New York ↔ Nairobi | Moves an hour at each US changeover and stays moved for the whole season |
| Opposite hemispheres | New York ↔ Sydney | Each end moves an hour in opposite directions, so the gap swings 1 + 1 = 2 hours across the year |
The Nairobi row deserves a moment, because nothing about it feels like a window. East Africa and India keep one offset all year, so their gap to shifting zones reshuffles for an entire season at a time: eight hours to New York all winter, seven for the whole daylight-saving stretch. Nobody on either end did anything wrong; one end's clocks simply moved.
Crossing midnight: the +1 nobody reads
Large gaps change the calendar date, not just the hour. In January an 18:00 call from New York reaches Nairobi at 18:00 + 8 = 26:00 — that is, 02:00 on the following date. The converter reports this as a day shift of +1: already tomorrow at the destination. Its own examples run both directions — 20:00 in Los Angeles is 07:00 the next morning in Nairobi, while 06:00 in Tokyo is still 16:00 of the previous day in New York, a −1. Whenever a gap crosses midnight, write the date beside each local time: "Tuesday's call" is genuinely Wednesday for one side, and that is how people dial in a day late.
Write the time so it cannot be misread
Half of cross-zone confusion is notation, not conversion. "The call is at 8" is ambiguous twice over — which 8, and whose 8? The 24-hour clock removes the first ambiguity: hours run 00 through 23, so 7:05 PM becomes 7 + 12 = 19, written 1905. The exceptions are the twelves — midnight is 0000, noon stays 1200 — and they are precisely the hours people convert wrongly, which is why the military time calculator handles both directions explicitly.
The second ambiguity — whose clock — is not solved by four digits, and the notation never claims to solve it: 1905 is a wall-clock reading, not a moment on Earth, until a place is attached. Attach a city, not an abbreviation. "EST" names the −5 standard-time offset specifically, so a July invite reading "3 PM EST" points at a clock nobody is running — Eastern time sits on −4 (EDT) by then. "15:00 New York time" survives every season, because the city resolves through whatever rules apply on the date.
Three edge cases that ambush recurring invites
Times that do not exist. On the March morning US clocks jump from 02:00 to 03:00, a 02:30 New York meeting names a time no wall clock will show. Scheduling tools — and the converter — roll it forward across the gap rather than erroring, which is where the invite lands anyway.
Offsets that are not whole hours. India runs at +5:30 and Nepal at +5:45, so a 12:00 UTC start is 17:30 in Mumbai (12:00 + 5:30) and 17:45 in Kathmandu — a top-of-the-hour call in one zone is perpetually half-past in another. The Chatham Islands even shift seasonally between +12:45 and +13:45.
Rules that change under you. In recent years Mexico, Egypt, Iran, Jordan and Syria have all changed their daylight-saving rules. The IANA database ships each change to phones and laptops as an update, which is why a converter that resolves per date stays right while a memorised offset table quietly rots.
The one-minute audit for any recurring meeting
Before a weekly cross-zone slot goes on calendars, run it through the converter twice — once on a January date, once on a July date. Identical answers mean the pairing is stable all year; different answers tell you which season it moves and by how much, and a US–EU pairing will additionally wobble through the March and autumn windows above. Then put the time in the invite in 24-hour notation, city named, date included, and the failure modes on this page have nothing left to grab.
Neither tool asks to be believed on faith. The converter prints the two UTC offsets it actually resolved for your date, and the military time page shows the four-digit and AM/PM readings side by side, so a suspicious reader can re-run the arithmetic in their head — transparency is the house rule across Quanta. And should one stubborn recurring meeting still refuse to reconcile — an invite that lands a day off for exactly one office, say — send us the details and we will walk through the conversion with you.