Daylight saving transitions are the hours when confident schedulers lose an hour they did not know existed or schedule two meetings in the same local hour twice. Spring forward removes a wall-clock hour; fall back repeats one. Converting “3:00 p.m. Chicago on November 2” to London without naming the date can land an hour off even for veterans. This guide walks through date-first conversion, the missing and repeated hour, confirming both cities’ DST status, and a checklist for recurring meetings that must survive the next clock change.
Pick the calendar date first
Offsets are not properties of cities alone; they are properties of cities at an instant. “New York to Paris” is incomplete. “New York to Paris on 2026-03-15 at 14:00 New York local” is computable. Always write the calendar date before you convert, especially for meetings within two weeks of a DST boundary.
Recurring series are dated objects stretched across time. A weekly call created in January carries rules that may break in March. When converting or auditing, pick one occurrence date — the next one, or the first occurrence after the transition — and run the math there. If that instance is correct, repeat for the first instance after the next transition.
Travel adds another date layer. A participant flying to Arizona mid-series may stop observing DST while the invite still says “EST.” The date of their travel matters as much as the date of the transition.
Convert with a zone-aware tool
Manual offset tables assume you already know whether each place is on standard or daylight time on your chosen date. Zone-aware tools encode government rules and answer that question for you. Enter source city, target city, local date, and local time; read the result; copy UTC as a tiebreaker if participants span several countries.
Avoid adding or subtracting a fixed hour learned in summer. “London is five hours ahead of New York” is true for part of the year and false for other parts. Tools that accept IANA names such as America/New_York and Europe/London sidestep abbreviation drift.
For batch conversions (migrating a whole quarter of marketing launches), export a small table of critical UTC instants and translate each row once. Consistency beats speed when legal or broadcast deadlines are involved.
Watch for the missing hour and the repeated hour
Spring forward: clocks jump from 2:00 a.m. to 3:00 a.m. (in typical U.S. implementations). Local times between 2:00 and 2:59 a.m. do not exist on that date. A meeting scheduled for 2:30 a.m. may shift, void, or land ambiguously depending on calendar software. Schedule spring-forward nights away from critical automation unless you enjoy incident reports.
Fall back: clocks return from 2:00 a.m. to 1:00 a.m. The hour from 1:00 to 1:59 a.m. happens twice. A recurring meeting at 1:30 a.m. may duplicate. Human meetings rarely use that hour; automated logs, billing batches, and cron jobs do. Audit systems that fire at local hour 1 on fall-back Sunday.
Cross-time-zone calls inherit the weirdness even when your city is calm. If you convert a Phoenix (no DST) slot through a DST-observing hub, the spring and fall instants still move under you. Convert at UTC when in doubt: UTC never repeats an hour.
Confirm both cities’ DST status
Many errors come from confirming one side. You know New York sprung forward; did London? European Union summer time starts and ends on different Sundays from U.S. rules. Sydney moves in October; New York moves in March. For each conversion, ask: on this date, is city A on daylight time, and is city B?
Non-observing pockets break assumptions inside countries. Arizona (except Navajo Nation), Hawaii, Saskatchewan, Queensland, and most of Brazil stay fixed while neighbors move. A participant’s city matters more than their country flag.
When status is unclear, read the UTC offset printed by a reliable tool for that date. UTC−4 vs UTC−5 for New York tells you more than arguing whether “EST” feels right in April.
A pre-flight checklist for recurring meetings
Two weeks before each DST weekend that touches your roster, run this list:
- Export recurring meetings that include any DST-observing zone.
- For each series, note the IANA zone on the organizer’s calendar entry, not the abbreviation in the title.
- Convert the next occurrence after transition Sunday using the actual date.
- Compare UTC time before and after; if UTC shifted but you intended a fixed UTC instant, fix the series.
- Send a one-line update to attendees with city labels and UTC offset.
- Delete duplicate fall-back instances if your tool created two rows at the same local label.
- Re-test automated reminders that use local hour triggers.
Document which meetings are anchored to local wall time (most standups) versus UTC (aviation, infrastructure). Local-anchored series should move with DST; UTC-anchored series should not. Mixing models in one invite guarantees drift.
After the transition, spot-check one live call attendance. No-shows on the first Monday after spring forward are a leading indicator that something still reads last month’s offset.
Convert any date and city pair on the Time Zone Converter before you edit recurring invites.
DST conversion errors are almost always date errors in disguise. Pick the day, use rules-aware tools, confirm both endpoints, and treat transition weekends as calendar maintenance windows. The hour you save may be your own.