Which 1:30? The Clock-Change Test Your AI Scheduler Needs

Which 1:30? The Clock-Change Test Your AI Scheduler Needs

By Anna with Oppy | November 8, 2026

A named time zone can still leave a booking ambiguous. Test repeated hours, missing times and cross-zone recurring appointments before your AI picks an instant for someone.

In HousingWire's November 5 coverage of NAR's 2026 buyer and seller profile, 90% of buyers used an agent, while 1% found their agent through AI. The profile covers closings from July 2025 through June 2026, not all prospective buyers. My reading: build AI around the human relationship, including the unglamorous precision of getting appointments right. 6

Consider a fictional overnight property-management callback: “November 1 at 1:30 a.m., New York time.” The assistant has the date, the time and the zone. What could possibly be missing?

Which 1:30.

NIST's daylight-saving rules identify November 1, 2026, at 2 a.m. local time as the end of that year's U.S. daylight-saving period. In observing regions, the clock returns to 1 a.m., repeating the hour. These are not worldwide rules. 1

For America/New_York, our fictional request therefore has two possible answers: 2026-11-01T01:30:00-04:00 and 2026-11-01T01:30:00-05:00. They correspond to 05:30 and 06:30 UTC. The named zone narrows the question. It does not finish it. 1 2

A calendar can resolve what a person has not

The useful surprise is in the iCalendar standard, RFC 5545. Section 3.3.5 says that an explicitly specified local date-time with a zone reference selects the first occurrence when that time repeats. For a nonexistent local time during a spring-forward gap, it uses the offset before the gap. 2

Those are interpretation rules, not questions about customer intent. They also do not establish how every Oppy account, calendar connector or library behaves.

Successful parsing is not proof that the intended time was selected. A system can produce an unambiguous timestamp by applying a default the customer never chose. The calendar is being decisive. That is not the same as being right.

The fix is a narrow exception check before booking, not another generic confirmation checklist.

Put clarification before conversion

Oppy's March 6, 2026 scheduling article documents Google Calendar availability checks, booking, invitations, reminders and rescheduling. Its Functions guide documents function permissions and human escalation. Neither establishes a native daylight-saving validator. 3 4

The following is proposed architecture, not a released Oppy module:

Request → Oppy clarification → external time validator → human review → authorized calendar action

Oppy preserves the original request and collects the full date, local start and end, and named zone. A deterministic validator uses maintained time-zone data to return the distinct valid UTC instants matching each local date-time.

Have the implementation check candidates by converting them back into the requested zone. Merely attaching a zone label is not sufficient validation.

Use three proposed results:

Validate both endpoints. If a booking crosses a clock change, ask whether its duration means elapsed minutes or a local-clock interval when that distinction affects the result.

Place this check in an authenticated connector or application workflow only after verifying that the actual account supports the necessary route. If no supported route exists, keep the process human-reviewed and draft-only. Do not assume that a general integration claim supplies a custom validation endpoint.

During the pilot, make booking and sending unavailable to the clarification role through actual access controls. A prompt is an instruction, not a permission boundary.

Give Oppy a small, explicit job

Supply approved explanations and validator results, then adapt this prompt:

ROLE: Clock-Change Clarifier

Preserve the person's original time request.
Collect full date, local start and end, and named zone.
Do not infer their zone from a phone number or location.

Use only validator results supplied by the approved
workflow or human reviewer. Do not calculate offsets.

If AMBIGUOUS:
Explain that the clock time occurs more than once.
Ask which supplied option they intend, in plain language.
Do not choose a default.

If NONEXISTENT:
Explain that the local clock skips this time.
Ask for a replacement. Do not shift it yourself.

If UNIQUE:
Draft the resolved local date-time and named zone.
Retain the supplied UTC instant in the internal record.

If validation is unavailable or contradictory:
Return UNVALIDATED and identify the human reviewer.

Never describe time resolution as booking confirmation.
Do not book, reschedule or send. Return a review draft.

For the repeated-hour case, a draft question could be: “Do you mean the first 1:30 a.m., before the clocks turn back, or the second 1:30 a.m., after they turn back?”

Keep the person's answer with the selected instant. An internal timestamp alone cannot explain why that option was chosen.

Replay the awkward hour without waking a customer

Use an isolated test calendar and synthetic requests. Replay these dated cases before connecting customer-facing actions:

Repeated hour: November 1, 2026, 1:30 a.m., America/New_York. Expect two candidates and a clarification draft, with no booking attempt. After selecting the second occurrence, the internal instant should be 06:30 UTC. 1 2

Missing hour: March 8, 2026, 2:30 a.m., America/New_York. Expect no valid candidate and a replacement-time question, not an automatic 3:30 booking. This deliberately tests a stricter workflow policy than the standard's explicit date-time interpretation. 1 2

Cross-zone recurrence: A fictional weekly staff check-in stays at 9 a.m. New York time on October 25 and November 1, 2026. Its Phoenix display should change from 6 a.m. to 7 a.m. Google Calendar's calendar and event documentation specifies a time zone for recurrence expansion. Check the returned instances, not just the first event. 1 5

Ordinary control: November 8, 2026, 1:30 a.m., America/New_York. Expect one candidate, 06:30 UTC, and a resolved draft without a repeated-hour question. A validator that blocks everything has invented a holiday. 1

Record expected and observed results for every case. Count ambiguous or nonexistent requests that reach a booking attempt without resolution, divided by all such test requests. Separately record unnecessary clarification on ordinary controls. Treat no unresolved booking attempts in this sample as a pilot acceptance criterion, not a future accuracy guarantee.

Have a person inspect the calendar's returned start and end instants before enabling broader use.

A good AI scheduler should not merely turn words into timestamps. At the clock change, it should recognize when the words still require a decision.

References

  1. NIST: Daylight Saving Time Rules. Updated February 9, 2026.
  2. RFC 5545: Internet Calendaring and Scheduling Core Object Specification. September 2009, section 3.3.5.
  3. Oppy: Stop Playing Phone Tag. Oppy Books It.. March 6, 2026.
  4. Oppy Functions: 52 Tools with Examples and Best Practices. August 22, 2025, updated May 7, 2026.
  5. Google Calendar API: Calendars and events. Technical documentation accessed November 8, 2026.
  6. HousingWire: Homeownership divides widen as older, wealthier buyers dominate 2026 market. November 5, 2026, reporting on NAR's 2026 profile.