How to Schedule Meetings Across Time Zones When Daylight Saving Time Changes
Your client says the weekly call is still at 9 a.m. Your calendar says it moved by an hour. Both can be right: the meeting stayed at the same local time for its organizer, while a daylight saving change altered the time difference between your cities.
The useful question is not just “What time is it there?” It is “What time will this particular meeting be in each location on that date?” A fixed time difference copied from last week can give the wrong answer.
Use the Meeting Timezone Planner to compare current working hours across your team's locations. For a future meeting, especially one spanning a clock change, also check the actual occurrence in your calendar.
The 2026 example: New York, London, and Karachi
The UK changed from British Summer Time to Greenwich Mean Time on 25 October 2026. US locations observing daylight saving time change on 1 November 2026. The dates come from GOV.UK and NIST.
That creates a week when London and New York are four hours apart rather than their usual five. Karachi stays at UTC+5 across these dates.
For a call anchored to 9 a.m. in New York, the same series looks like this:
| Meeting date | New York | London | Karachi |
|---|---|---|---|
| 22 October 2026 | 9:00 a.m. | 2:00 p.m. | 6:00 p.m. |
| 29 October 2026 | 9:00 a.m. | 1:00 p.m. | 6:00 p.m. |
| 2 November 2026 | 9:00 a.m. | 2:00 p.m. | 7:00 p.m. |
London's temporary one-hour difference ends when New York changes clocks. Karachi's time moves later because New York's 9 a.m. now occurs an hour later in UTC.
If instead the organizer anchors the call to 2 p.m. London, New York's time will change during the mismatch week. Always establish which location's clock the meeting is meant to follow.
1. Choose cities rather than a memorized offset
Use a named time zone such as America/New_York, Europe/London, or Asia/Karachi. A named zone carries the region's date-dependent rules. An offset such as UTC−5 describes a difference from UTC, but does not by itself describe when that location changes clocks.
For example, New York is UTC−4 on 29 October and UTC−5 on 2 November in this example. Calling both times “EST” hides that difference. In an invitation, “9 a.m. New York time” is clearer than using a seasonal abbreviation throughout the year.
Do not generalize one city's rule to an entire continent. Some places do not change clocks, and transitions can differ between regions. Select each participant's actual city or time zone.
2. Compare the hours your team can reasonably attend
Open the timezone planner, add participants, and choose their locations. You can also open this New York, London, and Karachi comparison.
The timeline compares the next 24 hours. Green represents the tool's standard working-hour band, amber represents early or late hours, and red represents overnight hours. Select a column to see that instant expressed in each location.
Treat those colors as a starting point for discussion. They do not know a colleague's shift pattern, lunch break, public holiday, or existing calendar appointments. A green cell means a time-of-day band, not confirmed availability.
If the only overlap is inconvenient for one person, agree on a rotation or send an asynchronous update. Moving a recurring call by 30 minutes can sometimes be more useful than insisting on the same round hour every week.
3. Verify the future date in your calendar
The planner's rolling timeline helps with near-term comparisons. It does not currently provide a picker for arbitrary future dates, so use your calendar to verify a meeting next week or next month.
When creating the invitation:
- Select the organizer's intended city time zone for the event.
- Enter the date and local start time in that zone.
- Set the recurrence if the meeting repeats.
- Open occurrences before and after the relevant clock changes.
- Ask participants to check the invitation in their own local calendar view.
For the example above, inspect the 29 October and 2 November occurrences separately. Checking only today's conversion will not establish the correct time for both.
Calendar apps place their time-zone controls in different locations. What matters is the zone attached to the event, rather than the display zone you happen to use while viewing it.
4. Share locations, then send the actual invitation
The planner's Copy Share Link button saves the selected participant labels and time zones in a URL. It is useful for sharing a team comparison without asking everyone to configure the same cities.
The link does not save a selected meeting instant or reserve anyone's time. When another person opens it, the timeline starts from their current moment. Use a calendar invitation to communicate the final date, start time, duration, and recurrence.
Before sending, compare these three descriptions:
| Description | What it establishes |
|---|---|
| “9 a.m.” | A time with no location or date |
| “9 a.m. New York time on 2 November 2026” | A specific local time and date that can be converted |
A calendar event in America/New_York |
A dated invitation whose time zone can be converted by participants' calendars |
For a recurring meeting, add a short note explaining which city's local time remains fixed. That gives people a way to check whether a one-hour shift is expected.
Common reasons a meeting looks wrong
A fixed UTC offset was used for a city that changes clocks. Replace the assumption with the city's named time zone and check the event date.
The conversion was checked on a different date. A screenshot from the previous week may show a different offset. Recheck the actual meeting occurrence.
The organizer and attendee changed clocks on different weekends. Compare both transition dates rather than applying one country's date to everyone.
The event is anchored to a different zone than expected. Decide whether the series should follow the organizer's local clock, another office's clock, or a fixed UTC time.
Someone is travelling. Their calendar's displayed local time may follow their current location. Confirm where they will attend from.
A short check before the next clock change
For every recurring cross-region call, identify the anchor city, inspect one occurrence on each side of the transition, and confirm the local time with the people affected. Keep the event's named time zone rather than manually adding or subtracting hours in its title.
Compare your team's working hours, then confirm the future date in your calendar. If the same question concerns a scheduled script rather than a meeting, the cron expression guide explains the schedule fields; check that system's configured time zone separately.