Author: Nadali. Prepared with AI assistance. Primary sources and calculations checked on 8 November 2026. All scenarios below are fictional.
Takeaway: when AI turns correspondence into a calendar, check more than the date and hour. You need a time zone, a recurrence rule and exceptions. A weekly supplier call usually needs to preserve one party’s local time. A hotel checkout deadline belongs to the hotel’s location.
For: small-business owners, hotel administrators, service coordinators and teams working with overseas suppliers.
“Every Monday at nine” sounds complete until one participant changes their clocks a week before the other. AI can read the words correctly and still create the wrong series because the message never specified the underlying rule. Agree on that rule before activating reminders.
1. Decide whose clock governs the schedule
Local wall time is the hour displayed in an office, such as 09:00. A time zone such as America/New_York determines its relationship to UTC on a particular date. UTC−04:00 is an offset, not a description of future seasonal changes. IANA updates time-zone rules as government decisions change. IANA’s explanation.
Ask: “Do we always meet at 09:00 in the supplier’s location, or preserve the same UTC time?” Suggest the first for an ordinary business meeting, but confirm the agreement. An automated operation might intentionally follow UTC.
Record the city and zone identifier together: “New York, America/New_York.” Do not rely on ET or EST alone for your review. If the location is missing, AI should ask rather than infer it from the language of an email.
2. Make AI show the rule in plain language
Prepare a short review card before creating the calendar entry:
- Original wording and a link to the message.
- First date, local start time and time zone.
- Frequency: every week, every other week, or another agreed pattern.
- Meeting duration and the final date or number of meetings.
- Cancellations, moved occurrences and unresolved questions.
A useful instruction is: “Extract these fields. Do not invent a missing time zone, duration or end date. Flag ambiguities and show the next three dates. Do not create events or send invitations yet.”
Use fictional contacts for the first test. You do not need a guest profile or a complete booking history to check a scheduling rule.
3. Test the week between two clock changes
Consider a call every Monday at 09:00 in New York. In London, it falls at:
- 14:00 on 19 October 2026;
- 13:00 on 26 October;
- 14:00 again on 2 November.
The UK changed its clocks on 25 October; New York changed on 1 November. These illustrative conversions use the official UK dates and US rules from NIST.
“Always 09:00 New York and 14:00 London” therefore cannot hold throughout the year. Agree whose local time stays fixed. Checking the first event is insufficient: inspect an occurrence before and after the transition in each zone.
4. Flag missing and repeated hours
In London, 01:30 did not exist on 29 March 2026; on 25 October, 01:30 occurred twice. An overnight arrival or shift handover needs an explicit decision in either case. UK clock-change rules.
RFC 5545, with verified erratum 4271, interprets a nonexistent local time using the UTC offset before the gap. A repeated local time refers to its first occurrence. These defaults do not establish your business agreement. RFC 5545, verified correction 4271 in the annotated text.
Confirm whether to skip the occurrence, move it to an agreed time or, for a repeated hour, use its first or second occurrence. Then inspect the result in the application the team actually uses.
5. Keep hotel checkout tied to the hotel
If a fictional London hotel requires checkout at 11:00, record the departure date and 11:00 in Europe/London. An owner’s travelling phone should not determine the guest’s deadline.
Check-in at 15:00 on 24 October 2026 and checkout at 11:00 the following day are 21 elapsed hours apart, not 20, because the clocks went back overnight. This calculation does not establish a room rate or the length of a billable night. The agreed booking conditions govern those questions.
Google Calendar can display the same event in each participant’s local zone. Tell a guest “11:00 local time at the hotel,” even if your own calendar displays another hour. Google Calendar help.
6. Separate dates, deadlines and durations
“Stocktake on 12 November” may be an all-day marker. “Return the keys by 11:00 on 12 November” is a timed deadline. Do not turn a date-only instruction into an invented midnight cutoff. Google Calendar represents all-day and timed events separately. Google’s event concepts.
Likewise, “tomorrow at 11:00” and “in 24 hours” can identify different moments across an offset change. iCalendar distinguishes calendar-day durations from exact hours. RFC 5545, section 3.3.6. Have AI preserve the wording and a responsible person clarify the intended meaning.
7. Move an occurrence without accidentally moving the series
“One hour later this Monday” changes one date. “One hour later from next Monday onward” changes the future schedule. Check the selected scope before saving.
Keep the moved event connected to its original occurrence. Google Calendar supports exceptions and identifies a rescheduled occurrence using its original start time. Recurring-event documentation. Afterwards, inspect both dates so the old appointment does not remain alongside its replacement.
The minimum review before launch
Have a responsible person check the first occurrence, clock changes, the final date and one exception. For “the last business day,” separately agree on the country and holiday calendar: the phrase alone does not identify local closures.
This workflow does not guarantee identical behaviour across calendar products. Inspect actual events after importing them, and recheck important upcoming appointments after time-zone rules change. AI can help express and verify a schedule; people and agreed terms still determine the deadlines.
For multilingual correspondence, also use our checks for dates, times and contact details in AI translations.
