Illustrative example — a collection after the clocks go back
Suppose a Leeds warehouse runs an overnight stocktake on Sunday 25 October 2026. The supervisor asks for a van at 1.30 am, after the crew has finished counting. In the UK that morning, clocks went back from 2 am British Summer Time to 1 am Greenwich Mean Time. The loading-bay clock showed 1.30 twice.
Both rows below are valid interpretations of the requested time. Only the supervisor knows which one fits the stocktake. A useful reply is “On Sunday the clock shows 1.30 twice. Do you want the first 1.30, before the clocks go back, or the second one, afterwards?” The answer can change which driver is available.
| What the crew sees | Time in UTC | What dispatch should offer |
|---|---|---|
| First 1.30 am, BST | 00:30 UTC | The earlier collection, if a van is free. |
| Second 1.30 am, GMT | 01:30 UTC | The later collection, if a van is free. |
Record what the customer actually specified
Give the assistant separate fields for the service date, local time and place of service. Allow each field to be unknown. When someone says “half one”, an after-hours service may need to ask whether they mean morning or afternoon. A prompt that demands a complete timestamp gives the model an incentive to fill that gap with a plausible answer.
Use the booked site to establish the time zone if that is your stated booking policy. A dispatcher in Belfast might be arranging work at a depot overseas. The time zone on the dispatcher’s laptop tells you little about when that depot opens. Show the site and its local date in the reply so the caller can correct either one.
For a relative request such as “tomorrow morning”, use the time of the original message and the agreed local zone to work out the date. An enquiry received just before midnight can wait in a queue until the next day. Read the resulting weekday and date back before committing the slot.
Make the booking system count the possible times
Pass the proposed date, time and named zone, such as Europe/London, to a time-zone-aware part of the booking system. Check whether that local time corresponds to zero, one or two instants. One practical check is to try each possible offset for the transition, convert to UTC and convert back. Keep distinct instants only when the return trip produces the requested local date and time.
On an ordinary day there will be one candidate. Search the diary for that slot. During the repeated hour there can be two. Python’s zoneinfo documentation shows how the fold setting distinguishes the earlier and later offsets. During the spring gap there are no candidates. In London on Sunday 28 March 2027, for example, the clock jumps from 1 am to 2 am. A request for 1.30 am that day needs a different time.
Calendar software can accept a value even when the customer’s intention is unresolved. The iCalendar specification defines how to interpret a local date-time with a referenced time zone when the clock repeats or skips a time. That convention lets systems exchange calendar data. A booking desk still needs to establish when the customer will open the gate.
Confirm the same slot in every system
Once the supervisor chooses the second 1.30, recheck the van and loading bay for that specific instant. Carry the chosen slot identifier into the booking request. If it has gone, offer the remaining choices. Switching to the first 1.30 because it is still free would change the agreement.
Save the confirmed instant alongside the site’s named zone so the diary, driver sheet and reminder can all describe the same collection. For the repeated hour, include “after the clocks go back” in the customer’s confirmation. A driver receiving a plain text message should be able to tell which journey it refers to without opening the booking system.
For a weekly appointment, ask whether the customer expects the same local clock time each week. A standing 9 am Monday collection in London moves by an hour against UTC when the clocks change. Keep the local schedule and zone for the series, then resolve each visit against the applicable rules.
Try three bookings before handing the diary to AI
Choose one site and test an ordinary 1.30 am, the autumn pair and the spring gap. Have a colleague act as the customer while the assistant uses a test diary. For each request, compare the spoken or written promise, the stored appointment and the driver’s reminder. On the autumn case, repeat the exercise with the other choice. You should see two different UTC times.
Decide who handles unresolved cases when the customer cannot reply. An overnight dispatch team might hold an enquiry for a supervisor. A daytime-only service can usually offer its next open slot immediately. Start with the hours you actually sell and give the desk one clear rule for when it can send a confirmation.