Name the record and zone that decide

Start with one safely simulated or approved appointment. Record the authoritative booking ID, calendar counterpart ID, original and requested local times with their named IANA zones, and the service zone that the business has decided controls the appointment. A visible clock conversion is not proof that the reschedule was accepted.

Google's Events resource documents event dateTime and timeZone fields. It says a time-zone offset is required unless a zone is explicitly supplied, and that recurring events require a zone. Those fields do not choose the controlling business policy or prove how your booking system maps a change.

Exercise one change and retain the observation

  1. Create one approved non-production appointment and retain the booking and calendar identifiers.
  2. State the original local display and IANA zone, then request one different local time and zone under the approved policy.
  3. Record the controlling service zone and the expected calendar counterpart that a reviewer will inspect.
  4. Record the observed counterpart result without claiming it represents every recurrence, permission, or notification case.
  5. Name who reconciles the records if the booking and calendar disagree.

The local fixture rejects a receipt that leaves the core boundary unnamed:

node --test sites/howtox.com/evidence/P136/reschedule-receipt.test.mjs

It does not call a provider, deliver a message, calculate an offset, or prove the live schedule is correct.

Stop when a calendar copy has no owner

Pause the rollout if the authoritative appointment, controlling zone, original or requested local display and zone, expected or observed calendar counterpart, or reconciliation owner is unknown. Do not ask staff to infer an appointment decision from an event that merely looks plausible.

For synchronization checkpoints and deleted entries, see Test Booking-to-Calendar Sync Before Staff Rely on It. For the separate delivery boundary, see Test an Application Notification Before Launch.

Does this receipt prove a provider handles daylight-saving changes correctly?

No. It makes one proposed exercise reviewable. A real provider, recurrence rule, permission model, and operating policy still need an approved environment-specific test.