Appointment Automation Time Zone Checklist
A booking is not ready for automation until the business, the calendar and the customer agree on what its time means. Use this checklist to specify that meaning before enabling confirmations or reminders—not just to check whether a calendar event was created.
By AI-Q Dynamics · Planning guide
Recommended planning worksheet. The policies, worked examples and test cases below are editorial recommendations and synthetic illustrations, not observed results or verified AI-Q product behavior. Confirm the actual source and destination contracts before enabling changes.
Choose the authoritative appointment time and zone
Start with one appointment source record and a named workflow owner. Ask which record is authoritative when a customer message, a staff calendar and a service-location schedule disagree. Record the service location's time zone separately from the zone used to display the appointment to the customer. Do not infer the intended zone from a phone number or the browser alone.
A time zone is not simply a permanent UTC offset. IANA maintains time-zone information and updates it to reflect political changes to boundaries, UTC offsets and daylight-saving rules. Record a named zone as well as the offset resolved for the particular appointment; an offset by itself does not describe future rule changes. IANA: Time Zone Database.
Recommended decision: preserve the customer's requested local date and time, the selected zone and the resolved instant together. Have the reviewer compare these values rather than accepting a screenshot that shows a clock time without a zone. If the calendar interface only displays an abbreviation, ask for evidence that identifies the actual zone used.
Separate one-off instants from recurring local schedules
For iCalendar, RFC 5545 distinguishes floating local time from a fixed time. Section 3.3.5 requires UTC time or local time with a time-zone reference to communicate a fixed time properly. This is an iCalendar rule, not a claim that every calendar API behaves identically. RFC 5545, section 3.3.5.
For a one-off appointment, ask whether each display points to the same intended instant. For a recurring appointment, first choose what must remain constant: the service location's wall-clock time, or a fixed UTC schedule. These are different requirements when offsets change. An illustrative request such as “the same local morning time each week” should not be rewritten as a fixed UTC recurrence without the owner's agreement.
Recommended review: inspect occurrences on both sides of an offset change, not just the first booking. Record the local display, zone and resolved instant for each inspected occurrence. Keep the recurrence rule with the appointment record, and identify who checks future occurrences when scheduling rules or the customer's preferred display zone change.
Handle missing zones, repeated times and nonexistent times
Some local times occur twice when clocks move back; others do not occur when clocks move forward. In iCalendar section 3.3.5, a repeated DATE-TIME refers to the first occurrence, while a DATE-TIME in a gap is interpreted using the offset before the gap. Those format interpretations are not permission to silently choose or move a customer's booking. RFC 5545, section 3.3.5.
Do not confuse that standalone DATE-TIME gap behavior with recurrence generation. Section 3.3.10 says recurrence-generated invalid dates or nonexistent local times must be ignored and must not count toward the recurrence set. It does not prescribe an “always shift” rule for every scheduling product. RFC 5545, section 3.3.10.
Recommended business policy: hold a booking with a missing zone; ask which occurrence is intended for a repeated local time; reject or clarify a nonexistent time rather than silently shifting it. For a recurring series, make skipped-gap handling visible to the owner and agree how the customer will be informed. Document the calendar's actual contract before deciding whether it can meet that policy. These recommendations may be stricter than a format's default interpretation.
Check confirmation and reminder timing end to end
Write the confirmation so the customer can identify the date, local time and intended zone. Compare it with the source record and staff display. A confirmation and calendar entry that show different local clock times can be correct if they represent the same instant in different zones; two identical clock labels are not proof of agreement.
Specify what “one day before” means in this workflow. Is it an elapsed lead time before the resolved appointment instant, or a particular local clock time on the previous calendar day? Treat these as separate business choices and test the chosen meaning across an offset change. Do not let a message template make that decision implicitly.
On reschedule or cancellation, inspect the current appointment and the intended reminder target together. Require evidence that a stale reminder is suppressed in the controlled test. Detailed recovery and replay controls belong in the duplicate-actions guide; this checklist stays focused on whether the action uses the correct time.
Copyable scheduling-time contract
Copy this record into your review document. Replace illustrative values with approved requirements; leave unresolved decisions visible. This page does not submit or store worksheet data.
- workflow owner
- Name the business owner who can settle conflicting time interpretations.
- appointment source record
- Record the authoritative record reference and revision; use a synthetic ID in examples.
- service location zone
- Name the service location's zone, not just its current UTC offset.
- customer display zone
- Record the customer's confirmed display zone and how it was obtained.
- local date/time
- Preserve the requested local date and clock time before conversion.
- resolved instant and offset
- Record the resolved instant and UTC offset for this occurrence.
- one-off or recurrence rule
- Choose one-off, recurring wall-clock time or fixed UTC recurrence; preserve the rule.
- ambiguous/nonexistent time policy
- State the hold, clarification or rejection policy; record occurrence selection explicitly.
- reminder lead-time meaning
- Choose elapsed lead time or previous-day local-clock scheduling and state the exact rule.
- change/cancel behavior
- Name the revised appointment version and how obsolete reminder targets are suppressed.
- expected calendar and message evidence
- List source values, staff/customer displays, confirmation preview and reminder target to compare.
- review owner/date
- Record the reviewer, date, outcome and unresolved decisions before enabling the workflow.
Six synthetic acceptance tests
These are recommended test specifications, not completed tests or customer results. Use an approved non-sending test environment and synthetic records. Capture expected and observed outcomes separately, and keep the reviewer and test date with the evidence.
1. Cross-zone display
Setup: View the same synthetic appointment in the staff and customer zones.
Pass/fail: Pass only when both displays resolve to the same intended instant and identify their zones. Fail on unexplained disagreement.
Evidence to capture: Capture the source record, selected zones, both displays and resolved instant.
2. Missing zone
Setup: Remove the zone from a synthetic booking request.
Pass/fail: Pass only when the booking is held for clarification, with no inferred final booking or reminder. Fail on an automatic guess.
Evidence to capture: Capture the missing input, hold reason and absence of a committed appointment or scheduled reminder.
3. Repeated local time
Setup: Use a local time that the tested zone's rules repeat, without choosing an occurrence.
Pass/fail: Pass only when occurrence or offset confirmation is required before booking; after confirmation, the result matches that choice. Fail on silent selection.
Evidence to capture: Capture the zone rules used, both candidate offsets, confirmed choice and calendar read-back.
4. Nonexistent local time
Setup: Use a local time that the tested zone's rules place in a gap.
Pass/fail: Pass only on documented rejection or clarification with no silent shift. Fail if the stored booking changes time without agreement.
Evidence to capture: Capture the requested time, gap evidence, disposition and destination state.
5. Recurring offset change
Setup: Create an illustrative recurring local appointment spanning an offset change and inspect a recurrence-generated gap case.
Pass/fail: Pass only when inspected occurrences match the approved wall-clock or fixed-UTC requirement and skipped-gap handling is visible. Fail on a mismatched occurrence or hidden omission.
Evidence to capture: Capture the recurrence rule, occurrence list, local/UTC comparisons and gap disposition; distinguish RFC format behavior from the business policy.
6. Cross-zone reschedule
Setup: Move a synthetic appointment to an agreed new time or zone after a reminder target exists.
Pass/fail: Pass only when the new calendar display and reminder target agree and the stale reminder is suppressed. Fail on an old active target or conflicting confirmation.
Evidence to capture: Capture old/new appointment versions, new confirmation preview, new target and old-target suppression evidence without sending a message.
Stop conditions and review handoff
Do not enable this workflow while its authoritative zone, repeated-time policy, recurrence meaning or reminder lead-time meaning remains unresolved. Also stop if the calendar evidence and message preview disagree, if a gap is silently shifted against policy, or if a rescheduled appointment retains an old reminder target.
Use synthetic appointments and a non-sending test destination. Record expected and observed results separately; a failure remains a failure until the corrected configuration is retested. Bring the completed contract, a sanitized example and the calendar's documented time semantics to the reviewer. This guide does not certify any implementation or establish that a particular integration is available.
AI-Q publicly describes CRM and calendar integrations. For the separate field-meaning decision, use the CRM Field Mapping Validation Checklist.
Sources and scope
Public source material reviewed September 15, 2026. Standards and third-party guidance support the scoped explanations above; they do not identify AI-Q suppliers or establish a particular implementation. RFC references are limited to sections 3.3.5 and 3.3.10; the RFC Editor page lists subsequent updates.
Bring the requirements to an integration review
Describe the workflow, the unresolved decision and the evidence you want to verify. Use sanitized examples; do not include credentials or confidential customer records.