ChatGPT, Claude, Copilot or Gemini · Practical walkthrough

Check a meeting time across a clock change with AI

London and New York don't change their clocks on the same day. An answer that subtracts five hours looks convincing and still puts your New York colleagues on the call an hour early.

Task by Task7 min read + practice

What you'll make

a checked meeting time for every office, with the full date in each place, and if you need it often, a small planner file that gets the clock-change weeks right.

What you'll need

your work AI account (ChatGPT, Claude, Copilot or Gemini), the meeting date, time and the place that time belongs to, and the places you’re comparing. Your Outlook or Google Calendar is useful for the check. About 10 minutes.

Example result.

Monday 26 October 2026	Local time
London (clocks went back on 25 October)	14:00
New York (clocks go back on 1 November)	10:00
Kolkata (no clock change)	19:30

1. Ask for the time with the date and the places

Give the AI the full date, the time and the place it belongs to. “14:00” on its own can’t be converted, because the offset between London and New York depends on the date.

A meeting is at [time] [place] time on [date].
What is the local date and time in [other places]?
Say whether any of these places changes its clocks within a week of that date,
and work from the date, not from a usual offset.

[time], [place] and [date] are the meeting as you know it, such as “14:00”, “London” and “26 October 2026”; [other places] are the cities you’re comparing.

Then check the answer in your calendar. In Google Calendar, open Settings › General › Time zone, tick Show additional time zones and pick a secondary zone. In new Outlook or Outlook on the web, open Settings › Calendar › View and choose Add time zone. Look at the meeting’s date, not today’s.

Why this works: asking about clock changes makes the AI look at the date. The calendar check gives you a second answer that doesn’t come from the AI at all.

What you should see: a time for each place, a note on any clock change that week, and the same times in your calendar.

2. Build a planner if you schedule across zones every week

For one meeting, the calendar is enough. If your team schedules across offices every week, or wants one page anyone can open, ask for a small planner. In Claude it opens as an artifact beside the chat; in Gemini, click Add files › Canvas first. Otherwise, save the code as planner.html and open it in your browser.

Two terms help. A named zone is a place-based name such as Europe/London, which knows when that place changes its clocks; “UTC+1” is right for London only half the year. A timestamp such as 2026-10-26T14:00:00Z names one exact moment: the Z means UTC.

Make a single HTML file I can open offline: a meeting time planner.
I enter a date, a time and the city it belongs to. It shows the full date, weekday and time
in Europe/London, America/New_York and Asia/Kolkata, using named time zones
and the browser's date-aware conversion. Never use a fixed number of hours between places.
If a time doesn't exist or happens twice on a clock-change night, say so and ask me which I mean.

Why this works: “never use a fixed number of hours” rules out the shortcut that breaks twice a year.

What you should see: a page with a date and time box and three converted times.

3. Test it in the clock-change week

Test the answer or the planner with two dates either side of a clock change, where you already know the right result. For 2026: on Tuesday 20 October, 14:00 in London is 09:00 in New York and 18:30 in Kolkata. On Monday 26 October, 14:00 in London is 10:00 in New York and 19:30 in Kolkata, because London’s clocks have gone back and New York’s haven’t yet.

Check the planner with 14:00 London on 20 October 2026 and on 26 October 2026.
I expect New York 09:00 then 10:00, and Kolkata 18:30 then 19:30.
Show what the planner displays for each, and add one late-evening meeting that falls on the next day in Kolkata.

Why this works: these two dates are exactly where a five-hour rule and a date-aware conversion disagree.

What you should see: both dates matching, and the late meeting showing the next day’s date in Kolkata.

Check the result

New York shows 10:00, not 09:00, for 14:00 London on 26 October 2026.
Every converted time comes with its full date, not just a weekday.
The answer names the date each place changes its clocks.
Your calendar’s second time zone agrees for the meeting’s date.

The usual failure: a fixed offset. The AI or the planner subtracts five hours from London all year, so on 26 October it says New York 09:00. Spot it by testing the week between 25 October and 1 November; any other week will look fine.

For 14:00 London on 26 October 2026 you gave New York as 09:00. London's clocks go back on 25 October,
but New York's don't change until 1 November, so the gap that week is four hours.
Redo the conversion from the date, for every place, and show the full date and time in each.

Worked example: two project calls a week apart

Fictional example. Ana runs a 14:00 London project call with colleagues in New York and Kolkata, on 20 October and again on 26 October.

Call 1: Tuesday 20 October 2026, 14:00 London
Call 2: Monday 26 October 2026, 14:00 London
Also invited: New York, Kolkata

First answer (wrong): “Both calls are at 09:00 in New York and 18:30 in Kolkata.” Ana’s Outlook second time zone shows 10:00 New York for the 26th.

Repair: the repair prompt above.

Repaired answer: 20 October: New York 09:00, Kolkata 18:30. 26 October: New York 10:00, Kolkata 19:30.

Both places moved on the 26th, but not for the same reason. London went back an hour, so New York’s gap shrinks to four hours. Kolkata doesn’t change its clocks, but it now sits five and a half hours ahead of London instead of four and a half.
The first answer was right for one call and wrong for the other. Only a test in the clock-change week shows that.
The calendar check took ten seconds and caught it before an invitation went out.

Try it

Give your AI-built tool a test that catches the bug

Keep the meeting at 14:00 in London and change the date. Compare the shortcut with the date-aware result, then use the stronger build request.

Use named zones and the date. A fixed five-hour subtraction is right on 20 October and an hour wrong on 26 October.

The example in text

20 October 2026 at 13:00 UTC: London 14:00, New York 09:00, Kolkata 18:30.
26 October 2026 at 14:00 UTC: London 14:00, New York 10:00, Kolkata 19:30.
The local display uses date-aware named-zone conversion. The contrasting five-hour rule is a deliberately faulty implementation; no calendars are connected.

Task kit for this job: Download (ZIP) · Reusable instructions

Go deeper

Times that happen twice, or not at all

On 25 October 2026, London’s clocks go back at 02:00, so 01:30 happens twice. In spring, a time in the skipped hour never happens. A good planner asks which one you mean rather than guessing.

That local time happens twice (or not at all) because of a clock change.
Don't choose one silently. Ask me which I mean, or for the exact timestamp,
then show it beside every converted time.

Turn the checked time into an invitation file

Once the time is right, the calendar file guide shows how to make an importable event and check it after import. A correct display doesn’t by itself make a correct event file.

Keep the test dates with the planner

Save the two test dates and their expected times next to the planner file. When someone changes it later, rerun them first. Next spring’s change works the same way: the UK moves forward on the last Sunday in March, the US on the second Sunday in March.