A weekly session can keep the instructor's local start time while changing the time another team sees, as the calculated example below shows.[4] For a learning-operations organizer, the useful question is which time the series is meant to preserve, and what happens to each occurrence after that choice.
This note proposes a MAJLS scheduling Virtual Employee that prepares an occurrence sheet and a precisely scoped change preview for an internal London–Dubai training series. It is a proposed operating design, not a demonstrated MAJLS integration or client result. The role prepares only; the named human organizer retains approval for consequential actions, including invitations, calendar edits and cancellations.
Agree what the recurrence preserves
Google Calendar uses IANA time-zone identifiers, and its API requires one time zone for expanding a recurring event.[1] Ask the organizer to choose the anchor before preparing the series: the instructor's wall-clock time in Europe/London, or a fixed UTC time. Do not silently replace one with the other.
Under this proposed workflow, collect the duration, review horizon, authorized calendar list, working windows and holiday inputs before checking availability. Keep zone identifiers beside local times. A label such as "London time" without the date and zone is insufficient for this sheet.
Calendar changes can apply to a whole recurring event or individual instances.[1] Scope therefore belongs in the request, rather than being inferred from "move training."
Filled example: three sessions, two holds
Everything in this operating example is illustrative. Organizer Maya Reed and instructor Sam Holt are fictional. Calendar states, names, policies and identifiers are synthetic; no calendar was connected or queried. The date/time conversions are calculated, not invented.
The filled recurrence-intent block is:
- Session: internal facilitation practice; draft reference
training-demo-01. - Organizer: Maya Reed; instructor zone
Europe/London; second team zoneAsia/Dubai. - Proposed anchor: instructor wall clock, Mondays 14:00–15:00 London; rule
RRULE:FREQ=WEEKLY;COUNT=3, starting 19 October 2026. Organizer acceptance of the anchor remains pending. - Review horizon: 19 October, 26 October and 2 November 2026, and no later occurrences.
- Assumed policy: Monday sessions must fit within London 09:00–17:00 and Dubai 09:00–19:00. The fictional holiday input lists no exclusions on these dates; this is not a claim about local holidays or employment rules.
- Fictional snapshot label: 2 October 2026, 09:00 UTC; all rows require a fresh authorized check before any approved send.
The conversions below use the data-only archive linked from IANA release 2026e.[4] They were calculated with Python zoneinfo against freshly compiled data and cross-checked with GNU date using the same zone files. The accompanying timezone-calculation-record.json retains dataset and file hashes; occurrence-review.csv contains full timestamps and per-calendar results.
| Original date | London start–end | UTC start–end | Dubai start–end | Synthetic checks and decision |
|---|---|---|---|---|
| 19 Oct 2026 | 14:00–15:00, UTC+01 | 13:00–14:00 | 17:00–18:00, UTC+04 | Both calendars: no busy intervals; within windows; candidate only |
| 26 Oct 2026 | 14:00–15:00, UTC+00 | 14:00–15:00 | 18:00–19:00, UTC+04 | London: no busy intervals; Dubai: busy 18:15–18:45; hold |
| 2 Nov 2026 | 14:00–15:00, UTC+00 | 14:00–15:00 | 18:00–19:00, UTC+04 | London: no busy intervals; Dubai: notFound error; hold |
All local dates match the original date in this example. The calculated change is visible: keeping London at 14:00 moves Dubai from 17:00 to 18:00 after the first occurrence.[4] Anchoring instead at 13:00 UTC would keep Dubai at 17:00 and put London at 13:00 on the last two dates.[4] Maya must choose which relationship is intended.
Google's free/busy reference returns busy ranges and permits per-calendar computation errors.[2] Its intervals have inclusive starts and exclusive ends.[2] For this MAJLS sheet, compare each complete session interval against every authorized calendar's returned intervals. Mark a busy overlap as busy and an error as unknown; neither becomes "checked free." Do not copy confidential event titles or absence reasons into the organizer's sheet.
Treat availability, organizer authorization and attendee responses as separate fields. This proposed workflow does not treat a free/busy snapshot as a reservation, an acceptance or permission to send.
Filled example: move only 26 October
Google's recurring-events guide identifies recurringEventId as the parent series ID and originalStartTime as the instance's original recurrence time; the latter still identifies the instance after it moves.[3] Preserve both original and proposed times in the packet. Google's guide also warns against individually modifying instances when the intended change is the whole series or "this and following."[3]
For this change rehearsal, assume a series exists in a fictional calendar. Its synthetic IDs stand in for retrieved records; a real request must use verified destination identities, not invented ones. The private change preview is:
| Field | Filled illustrative value |
|---|---|
| Parent series ID | demo-training-series-01 |
| Instance ID | demo-training-instance-20261026 |
originalStartTime |
2026-10-26T14:00:00+00:00, zone Europe/London |
| Current start | Same as original; not yet changed |
| Proposed session | 26 Oct, London 13:00–14:00; UTC 13:00–14:00; Dubai 17:00–18:00 |
| Requested scope | This occurrence only; retain 19 Oct and 2 Nov as separate review rows |
| Policy and availability | Proposed interval fits both assumed windows; synthetic alternative snapshot shows no busy intervals on either calendar; final recheck still required |
| Audience | Same two fictional training cohorts; organizer must confirm actual authorized recipient list |
| Decision | Maya's approval pending; no invitation or edit performed |
The proposed conversion uses the same IANA dataset.[4] Moving this occurrence does not resolve the inaccessible calendar on 2 November. That hold belongs to the calendar owner; the assistant must not expand a proposed one-occurrence change into a series change.
Draft invitation preview, private and unsent: "Proposed change to the 26 October facilitation session only: 13:00–14:00 Europe/London / 17:00–18:00 Asia/Dubai. Other dates remain subject to their own checks. Organizer approval and a fresh availability check are outstanding."
First-run checklist
Before preparing a real series:
- Have the organizer accept the anchor, horizon, policy inputs and exact audience.
- Convert every occurrence in the horizon with maintained zone data. Hold ambiguous or nonexistent local times rather than choosing an offset silently.
- Hold inaccessible calendars, missing results, busy overlaps or stale snapshots; route each failed condition to its owner.
- Match parent, instance and original start before presenting a one-occurrence change. Send unclear scope back to the organizer.
- Require the organizer to authorize the final send or edit after rechecking availability. A model confidence score cannot waive a hold or supply approval.
Start with the filled sheet, not an autonomous booking feature. The first review should establish whether Maya can see the anchor choice, the two different holds and exactly which occurrence the change would affect.