Check Meeting Time Zones with ChatGPT Across the 2026 DST Gap
A weekly meeting can stay at 09:00 in New York while changing time for colleagues elsewhere. In late October 2026, Madrid leaves summer time a week before New York leaves daylight saving time. That creates a short gap when a familiar time difference is wrong.
Ask ChatGPT to organize the meeting dates and flag exceptions, then verify each conversion independently. The example below is a fictional editorial reference, not a record of a ChatGPT run or a calendar invitation.
Choose the clock that stays fixed
Start with the meeting’s goal and anchor rule. Here, a team wants a 30-minute Friday call that always runs from 09:00 to 09:30 in New York. The source zone is America/New_York; the other zones are Europe/Madrid and Asia/Seoul. The dates are October 23, October 30, and November 6, 2026.
“Keep 09:00 in New York” differs from “keep 13:00 UTC.” The former follows New York’s seasonal clock changes. The latter preserves one UTC time and lets New York’s local time move. Decide which rule reflects the team’s agreement before converting anything.
Use city-based zone identifiers with full dates. IANA’s timezone guidance explains that named zones carry clock-transition rules and warns that abbreviations such as CST and IST can identify different places. A numeric offset describes an occurrence; it does not replace a zone’s future rules.
Check all three Fridays across the gap
Spain’s published calendar sets the end of summer time on October 25, 2026: mainland clocks move from 03:00 back to 02:00. NIST’s 2026 rules put the US change on November 1 at 02:00 local, when clocks return to 01:00. Those different dates explain the middle row.
We independently calculated the reference starts below using date-aware timezone rules and checked the 2026 change dates against the linked official sources. They follow the fixed New York local-time rule. Every location’s meeting falls on the same date in this example. On a narrow screen, swipe the table sideways to see every column.
| Date | New York start | Madrid start | Seoul start | UTC start |
|---|---|---|---|---|
| Friday, 2026-10-23 | 09:00 (UTC−04:00) | 15:00 (UTC+02:00) | 22:00 (UTC+09:00) | 13:00 |
| Friday, 2026-10-30 | 09:00 (UTC−04:00) | 14:00 (UTC+01:00) | 22:00 (UTC+09:00) | 13:00 |
| Friday, 2026-11-06 | 09:00 (UTC−05:00) | 15:00 (UTC+01:00) | 23:00 (UTC+09:00) | 14:00 |
Each call lasts 30 minutes, so add 30 minutes to every listed start for its end. Seoul’s 22:00 and 23:00 starts are late: get the participants’ agreement or choose another anchor time. A correct conversion alone does not make a workable schedule.
Verify the dates and catch ambiguous times
Give the assistant the full specification and request one row per occurrence, including each local date, start, end, offset, and UTC start. Use the reusable meeting timezone prompt to structure that check.
Independently reproduce each conversion in a date-aware timezone tool using the same named zones. Check the actual dates rather than applying today’s offset to every week. Compare the results with the reference table and resolve disagreements before proceeding.
Clock changes introduce another trap: some local times repeat in autumn or do not exist in spring. Madrid’s 02:30 on October 25, 2026 occurs twice, as does New York’s 01:30 on November 1. The Friday morning anchor avoids those hours. For another schedule, resolve the intended instant explicitly before accepting a table.
Inspect the calendar before inviting people
Create a draft series with the agreed source zone, then open the actual October 23, October 30, and November 6 occurrences in your calendar. Confirm their starts and ends in each participant’s zone before sending invitations. Keep timezone data current and recheck if the schedule or rules change.
This is a longstanding scheduling problem: a 2014 public calendar question asks how UTC and recurring event times should be handled. For work periods that cross midnight, use the separate overnight shift availability workflow to account for work and travel buffers.
Photo: feinschliff / Unsplash.
