Why "9 AM London, Every Monday" Arrives at 3 AM in New York Some Weeks — DST, Offset Arithmetic, and Scheduling Global Teams

"What time is it in Tokyo right now?" is a simple question with a simple answer — but "schedule a recurring meeting that works for London, New York, and Tokyo every week of the year" has no simple answer, because Tokyo doesn't observe daylight saving time and the New York-London offset changes twice a year, producing meetings that shift by an hour relative to Tokyo participants at DST transitions

The previous articles on this site covered UTC offsets and DST basics, the world's strangest timezones, scheduling across timezones, and the IANA database vs hardcoded UTC offsets. This article addresses the specific meeting scheduling problem for global teams — the arithmetic of finding windows, how DST transitions affect existing meeting slots, and the organizational conventions that reduce timezone friction.

The offset arithmetic problem: finding a window that works

Finding meeting overlap windows requires knowing the UTC offset for each timezone at the specific date and time of the proposed meeting — not the "standard" offset, but the offset including DST adjustments for that location on that day.

A specific example — a weekly Monday 9 AM London meeting:

The 3-week period in March when the UK has switched to BST but the US hasn't yet switched to EDT creates a 3 AM local time for New York participants — potentially unworkable. The same meeting, same day of week, same "9 AM London" instruction, arrives at completely different local times in New York depending on the week.

Why scheduling by "local time" is fragile

"We meet Mondays at 9 AM London time" breaks down because:

1. The meeting is in a calendar system that stores the absolute UTC timestamp
2. Participants see their own local time conversion
3. The conversion changes at DST transitions — the absolute UTC time stays constant, but the local interpretation shifts

"We meet at 09:00 UTC" is more stable for global teams — UTC doesn't observe DST. But it means participants' local times shift with their own DST transitions:

• In UK winter: 9:00 UTC = 9:00 AM local
• In UK summer: 9:00 UTC = 10:00 AM local (BST)

Calendar applications that correctly handle timezone-aware recurring events (specifying "9 AM in Europe/London, recurring weekly") will automatically adjust the underlying UTC representation at each DST transition, so the meeting always shows at 9 AM London regardless of BST/GMT shifts. This is the correct approach — but requires the calendar application to properly store and handle the timezone identifier (not a UTC offset).

Non-DST timezones: the hidden scheduling advantage

Countries and territories that don't observe DST have stable offsets year-round. Their UTC offset doesn't change — they're permanently on a single standard time.

Notable non-DST locations:

• Japan (UTC+9) — no DST; JST year-round
• India (UTC+5:30) — no DST; IST year-round
• China (UTC+8) — no DST; CST year-round
• Most of Africa — minimal DST observance
• Singapore (UTC+8) — no DST

For scheduling with non-DST locations: the offset to these locations changes from the perspective of DST-observing countries. A US-based company scheduling with Tokyo will find that the Tokyo meeting time shifts by 1 hour relative to US local time when the US switches between EST and EDT — even though Tokyo's offset never changed.

The advantage for scheduling analysis: non-DST timezones are predictable year-round. "The Tokyo window" is always the same relative to UTC; only the DST-observing countries' windows shift.

The "follow the sun" model and timezone shift handoffs

Large global teams sometimes use "follow the sun" work patterns where different regional teams hold coverage during their business hours, with handoffs between them. Engineering teams might have European coverage (8 AM-6 PM CET), Asian-Pacific coverage (8 AM-6 PM JST), and American coverage (8 AM-6 PM EST/EDT).

The timezone handoff challenge: the handoff time between teams needs to be defined in UTC to be unambiguous. "The Asia-Pacific team hands off to Europe at 00:00 UTC" remains stable year-round. "The handoff is at 9 AM Singapore time to 9 AM Amsterdam time" is ambiguous when the two locations' local-to-UTC translations differ by season.

DST creates asymmetric handoff windows: during the months when Europe observes CEST (UTC+2) but the US is still on EST (UTC-5), the European-American handoff window shifts by an hour relative to the rest of the year — potentially creating a 1-hour gap or overlap in coverage that's invisible in local-time thinking but visible in UTC.

The Outlook and Google Calendar DST problem

Calendar events stored with the wrong timezone metadata produce a specific DST failure mode:

A recurring weekly event created with a hardcoded UTC offset (UTC+1, "London in summer") will show at the wrong time during winter when London is at UTC+0. An event stored with the timezone identifier (Europe/London) will correctly show at the same "local clock" time regardless of DST — because the calendar converts "9 AM Europe/London" to the correct UTC time for each specific occurrence.

The diagnostic: if a recurring event shows at the wrong time after a DST transition, the timezone is probably stored as a UTC offset, not as an IANA timezone identifier. Recreating the event with a properly specified timezone (not an offset) fixes it.

How to use the Time Zone Converter on sadiqbd.com

1. For finding meeting windows: convert a proposed time across all participant timezones to verify no one is at an unreasonable local time; check the same proposed time for both summer and winter dates if scheduling a recurring meeting that spans DST transitions
2. For the March gap: specifically check times in the 3-week period when UK has switched to BST but US hasn't yet switched to EDT — this window often produces unexpected shift in US participants' local times
3. For Tokyo / India / China scheduling: these don't shift with DST, but the relative offset to DST-observing countries changes twice a year — verify both the summer and winter relative offsets when creating recurring meetings

Frequently Asked Questions

Is there any time that works reasonably well for all three major business regions (Americas, Europe, Asia-Pacific) simultaneously? For all three at once, no — there's no good window. The time difference between San Francisco (UTC-8 in winter) and Tokyo (UTC+9) is 17 hours. A 9-5 workday in San Francisco (9 AM = UTC 17:00) is 2 AM in Tokyo. Any time that's business hours in both California and Tokyo is either very early morning California (5-7 AM) or late evening Japan (9-11 PM). The realistic options are: a short morning window in the Americas that's evening in Europe and late night in Japan; or a "rolling" meeting schedule that rotates to distribute the inconvenience fairly. For true global teams, the "follow the sun" model with asynchronous communication between regional overlaps is more practical than forcing everyone into the same meeting time.

Is the Time Zone Converter free? Yes — completely free, no sign-up required.

Try the Time Zone Converter free at sadiqbd.com — convert any time between world timezones, with DST-aware results for any date.