Scheduling across time zones and daylight saving time

Anchor every meeting to a named place, such as a city or its IANA zone name (America/New_York), instead of an abbreviation or a fixed offset. Then check each attendee’s local time on the actual meeting date. The US, Europe and the southern hemisphere change their clocks on different dates, and many places never change them. So a weekly meeting that stays put for the organizer moves by an hour for someone else: for one to three weeks at a time between New York and London, and for months at a time between New York and Sydney.

When do the clocks change in 2026 and 2027?

In 2026 the US changes its clocks on March 8 and November 1, and the UK and EU on March 29 and October 25. New Zealand and parts of Australia go back on April 5 and forward on September 27 (New Zealand) or October 4 (Australia). All dates are local dates. Zone names like America/New_York come from the IANA Time Zone Database (the tz database), the record of clock rules that software uses to work out local time.

In the southern rows, “Back 2026” ends the season that began in 2025, and “Forward 2026” starts the one that ends in April 2027. The dates are computed from release 2026c of the IANA tz database each time this site is built. If one matters, confirm it with the local authority, such as the official pages in Sources.

• US: each zone switches at 2:00 a.m. on its own clock, so the change reaches Chicago an hour after New York and Los Angeles three hours after. A state can opt out of daylight saving entirely. Hawaii and most of Arizona do.
• UK and EU: the UK goes forward at 1 a.m. and back at 2 a.m. In the tz data, every UK and EU zone switches at the same instant, 01:00 UTC. That is 2 a.m. in Paris going forward.
• Southern hemisphere: clocks go forward in September or October and back in April, the opposite of the north.
• Canada in 2026: according to the tz database’s 2026 release notes, British Columbia (UTC−7), Alberta (UTC−6) and Manitoba (UTC−5) stay all year on the time they sprang forward to on March 8, 2026, and the Northwest Territories is staying on UTC−6 as well. None of them falls back on November 1, 2026. From then on, Vancouver (UTC−7 all year) is an hour ahead of Seattle in winter, when Seattle is on standard time (UTC−8), and level with it in summer, when Seattle is on daylight time (UTC−7).

Why is New York only 4 hours behind London for a few weeks?

The US springs forward two or three weeks before Europe (three in 2026, two in 2027) and always falls back one week after it. During those weeks New York is on summer time (EDT, UTC−4) while London is on winter time (GMT, UTC+0), so the usual 5-hour gap shrinks to 4.

• 2026: March 8–28 and October 25–31
• 2027: March 14–27 and October 31 to November 6

If both offices work 09:00–17:00, they normally overlap for 3 hours, 09:00–12:00 in New York (14:00–17:00 in London). In the mismatch weeks the overlap grows to 4 hours, 09:00–13:00 in New York (13:00–17:00 in London).

Every US zone that uses daylight saving has the same one-hour mismatch with the UK and the EU in those weeks. For example, Chicago is 6 hours behind Paris instead of 7. The southern hemisphere adds a third pattern, because Sydney’s clocks move in the opposite direction. That gives the New York–Sydney gap three values in one year: 16, 15 and 14 hours.

How much does a weekly meeting move over a year?

Usually by an hour at a time, on dates that depend on where each attendee is. In the 2026 example below, the London attendee’s call moves on four Tuesdays and the Sydney attendee’s has three start times.

Example inputs: a team based in New York holds two weekly calls on Tuesdays, both anchored to New York time. One is at 10:00 with London. The other is at 17:00 (5 p.m.) with Sydney, which is Wednesday morning there.

To convert, turn the New York time into UTC using New York’s offset on that date. Then add the other city’s offset on that date:

Here $o$ is the UTC offset in hours on the meeting date, for example $-4$ for EDT. Add or subtract 24 hours to wrap into the next or previous day.

Take Tuesday, October 27, 2026:

1. New York falls back only on November 1, so it is still on EDT, $o_{\text{NY}} = -4$. The 10:00 call is at $10 - (-4) = 14$, which is 14:00 UTC.
2. London fell back on October 25, so it is on GMT, $o = 0$. The call starts at 14:00 in London. A week earlier it started at 15:00 (BST, UTC+1).
3. The 17:00 call is at $17 - (-4) = 21$, which is 21:00 UTC. Sydney has been on AEDT since October 4, $o = +11$, so $21 + 11 = 32$. After wrapping, that is 08:00 Wednesday.

Repeating that for every Tuesday in 2026 gives this pattern:

Nothing changes on the New York side. The London attendee’s call moves on four Tuesdays (March 10, 17 and 24, and October 27). The Sydney attendee has three different start times and is at 07:00 (AEST, UTC+10) for half the year. A general “London is 5 hours ahead” rule gets 4 of the 52 Tuesdays wrong, and a single “Sydney is 15 hours ahead” rule gets 44 of them wrong.

Why are abbreviations like CST and IST unreliable?

The same letters stand for different offsets in different countries, and the tz database’s own documentation warns about it. These are the offsets in the tz data for 2026:

From November 2026 the tz data also uses CST for Alberta and the Northwest Territories, which now stay on UTC−6 all year, MST for British Columbia (UTC−7 all year) and EST for Manitoba (UTC−5 all year).

A fixed offset avoids the ambiguity but not the seasons: “UTC−5” matches New York only in winter, because a fixed offset does not follow daylight saving. A city name or IANA name carries the whole rule set, so “10:00 New York time” is right in any month.

What happens to a meeting at 2:30 a.m. on the night clocks change?

On the night clocks go forward, 2:30 a.m. never happens in New York, Paris, Sydney or Auckland. On the night they go back, one hour happens twice. In New York on March 8, 2026, clocks jump from 01:59:59 EST to 03:00 EDT, so 02:00–02:59 is skipped. On November 1, 2026, they go from 01:59:59 EDT back to 01:00 EST, so 01:00–01:59 happens twice, an hour apart.

Software has to choose an interpretation. The iCalendar standard (RFC 5545), which calendar invites use, reads a skipped time with the offset from before the gap. So 02:30 on March 8 becomes 03:30 EDT (07:30 UTC). For a repeated time it picks the first occurrence: 01:30 on November 1 means 01:30 EDT (05:30 UTC), not 01:30 EST (06:30 UTC). Other tools may ask you to choose, or may choose differently.

The same nights change elapsed time. In New York, a shift from 22:00 on Saturday, October 31 to 06:00 on Sunday, November 1, 2026 lasts 9 hours, not 8. The same shift on March 7–8 lasts 7 hours. A countdown from noon on Saturday, October 31 to noon on Monday, November 2 spans two calendar days but 49 hours. One-off events and automated jobs avoid both problems if they fall outside the skipped and repeated hours in every attendee’s zone. For the zones in the table, that means outside 01:00–03:00 local time on the change dates.

Which places use 30- or 45-minute offsets?

India, Iran, Afghanistan, Myanmar, Newfoundland and central Australia are among the places on half-hour offsets. Nepal, New Zealand’s Chatham Islands and the Eucla area of Western Australia use 45-minute offsets. Counting in whole hours gets all of them wrong. Offsets from the tz data for 2026:

Because India never changes its clocks, the New York–India gap changes only when New York’s clocks do. A 09:00 New York call is at 19:30 in Kolkata in January (10 hours 30 minutes ahead), but at 18:30 in July (9 hours 30 minutes ahead). Kathmandu is another 15 minutes later: 19:45 and 18:45. Lord Howe Island is unusual in another way: its daylight saving shift is 30 minutes, not an hour.

Which time zone should a recurring meeting follow?

No choice is neutral: the zone a series follows keeps the same local time all year, and anyone whose clock changes don’t match that zone’s absorbs the shift. A recurring invite stores its start as a local time in one zone, usually the organizer’s. RFC 5545 recommends this so that every occurrence starts at the same local time across daylight saving changes. Everyone else’s time is derived from it, so their time moves whenever the rules diverge.

Whichever anchor you pick:

• Name it in the invite: “Tuesdays 10:00 New York time” tells attendees which clock is fixed.
• Check the change windows: in February and again in early September, look at the next ten or so weekly occurrences in every attendee’s zone, not just the next one. Those two windows cover all the changes in the table above.
• Consider splitting the series: when one attendee’s slot sits at 07:00 for six months, as Sydney’s does above, a second series for that half of the year is an option. The cost is keeping two series in step.

What can still go wrong?

• Rules change. Future conversions assume today’s rules, and governments change them, sometimes at short notice. The tz release recording Manitoba’s move to permanent UTC−5 came out on September 29, 2026, about a month before its clocks would have gone back. The tz documentation gives the case of a meeting converted from Dublin time before Ireland changes its rules. If you store the meeting as local time plus zone and convert only when you look, the conversion uses whatever rules are current then.
• Devices lag behind. Phones, computers and browsers get new rules through software updates. A device with older tz data still shows Vancouver falling back on November 1, 2026 and every November after that. Browser-based tools, including the meeting planner, use the browser’s copy of the rules.

Try it

• Meeting times: open the Time Zone Meeting Planner and set the meeting date to 2026-10-27, the start time to 10:00 and your time zone to America/New_York. Replace the example’s other time zones with Europe/London and Australia/Sydney. You should see London at 14:00 on Tuesday (GMT, UTC+00:00) and Sydney at 01:00 on Wednesday (AEDT, UTC+11:00). The planner also flags the London change on October 25 and the New York change on November 1. Change the date to 2026-11-03 and London moves to 15:00, Sydney to 02:00 Wednesday. For the Sydney call, set the start time to 17:00 and the date to 2026-04-07 to see 07:00 Wednesday.
• Skipped and repeated times: in the same planner, keep America/New_York and enter 2026-03-08 at 02:30. The planner says 02:30 doesn’t exist that day and uses 03:30 EDT, the iCalendar reading, unless you pick 01:30 EST. Then enter 2026-11-01 at 01:30 to choose between 01:30 EDT, the first time, and 01:30 EST, the second.
• Shift length: in the Time Duration Calculator, choose time between two clock times: a start time of 22:00 and an end time of 06:00 give 8:00:00, with the end on the next day. It counts clock time and does not model DST. For the October 31 night, switch to the total of durations and add 8:00 and 1:00 to get 9:00:00. For March 7–8, set the 1:00 row to subtract to get 7:00:00.
• Countdowns: in Countdown to a Date, a target of 2026-11-01 01:30 in America/New_York asks which 01:30 you mean. A countdown that crosses a change is one hour longer or shorter than days × 24.