EXDATE or RECURRENCE-ID: skip one meeting or move it to another day
Skipping a weekly meeting and moving that same meeting are different operations. EXDATE removes a generated start; a recurrence override can retain the instance’s identity while giving it a different start. The distinction matters when diagnosing a missing or doubled appointment.
Two different outcomes from the same original series
| Intended outcome | Relevant original identity | Expected visible starts |
|---|---|---|
| Skip 9 November | EXDATE:20261109T090000Z | 2 and 16 November at 09:00Z |
| Move 9 November to 10 November | RECURRENCE-ID:20261109T090000Z; new DTSTART:20261110T140000Z | 2 November 09:00Z; 10 November 14:00Z; 16 November 09:00Z |
| Create an unrelated extra event | A separate event identity | May look similar; series relationship not established |
Start with a three-date schedule
Imagine a fictional weekly series starting at 09:00Z on 2 November 2026 with COUNT=3. Its ordinary starts are 2, 9 and 16 November. If the 9 November meeting is cancelled with no replacement, an exclusion of that original start leaves 2 and 16 November.
RFC 5545 section 3.8.5.1 defines EXDATE as a set of exceptions removed from the recurrence set. Its values must use the matching value type. Excluding an occurrence is not itself a new start time for that occurrence.
Retain original identity when an instance moves
Suppose instead that the 9 November meeting moves to Tuesday 10 November at 14:00Z. Section 3.8.4.4 defines RECURRENCE-ID using the original scheduled DTSTART of that instance. The override therefore refers to RECURRENCE-ID:20261109T090000Z even though its new DTSTART is 20261110T140000Z.
The override belongs to the same series UID. Using 10 November as the recurrence identifier would describe a different identity, not simply document the new time. The field identifies which original occurrence is being changed; the new DTSTART describes where it goes.
Do not confuse a matching date list with matching identity
Adding a separate event on 10 November and excluding 9 November can make a screen show the same dates. That does not establish that the separate event retains the original recurrence relationship, invitation state or later update behavior. Identify which operation your provider actually performed.
RFC 5545 also supports RDATE as an additional inclusion date. A union of dates and an override of an identified instance answer different structural questions, even when the resulting grid initially looks similar. A screenshot alone cannot prove how a series exception is represented.
Check the source and neighboring dates
For the fictional move, verify 2 November stays at 09:00Z, 9 November no longer shows the ordinary meeting, 10 November shows the replacement at 14:00Z and 16 November remains unchanged. Record the owning calendar and organizer as well as the visible dates.
This is an interchange diagnostic, not a claim that Cloud Calendars exposes raw EXDATE, RDATE or RECURRENCE-ID editing. Use the original provider’s supported single-instance change when necessary. Do not rewrite a real file or recreate the series just to investigate one unfamiliar field.
What it looks like
Cloud Calendars overview, using our product images. Provider settings and protocol examples described in this guide are separate from the screens shown here.
What to do
- Write the original scheduled start before changing one occurrence.
- Decide whether it is being skipped, moved or replaced by an unrelated event.
- For a move, distinguish the old recurrence identity from the new start.
- Check the changed date and neighboring occurrences at the owning source.
Questions
- Why does RECURRENCE-ID show the old date after a move?
- That is its purpose: it identifies the original occurrence being changed. The new DTSTART supplies the moved time.
- Does EXDATE itself specify the replacement time?
- No. It excludes starts. A replacement requires an appropriate additional representation or supported provider operation.