Modified Occurrence Alarm: Recurring Event Exceptions

Does a calendar alarm know when one occurrence of a recurring meeting changes?

Sometimes. If the alarm app reads the calendar as a flat list of events rather than a recurrence rule plus exceptions, a rescheduled Tuesday standup can fire at the old time, fire twice, or not fire at all for that one week.

The mechanism behind this is older than any iOS feature. A recurring meeting isn't stored as fifty-two separate events — it's one master event with a repeat rule, and any occurrence someone edits individually gets split off into its own record that overrides the rule for that date only. Whether an alarm app correctly follows that override, or just keeps reading the stale rule, decides whether the alarm rings at the right time. This is the same underlying issue covered in why recurring events get the wrong alarm time, but it specifically concerns the one-off edit, not the whole series.

How does a calendar actually store a single changed occurrence?

It creates an exception record tied to the original instance, not a new standalone event. In the iCalendar standard (RFC 5545), a recurring event carries an RRULE for the pattern and, when one date is skipped or altered, an EXDATE or a second VEVENT block identified by a RECURRENCE-ID matching that instance's original start time.

If the RECURRENCE-ID is the original start time of the modified event, and the UID on both events is the same, calendar software can connect the dots and figure out that the exception event replaces an instance in the series which was originally to occur at that time. Google Calendar's API models this the same way: a recurring event consists of several instances, its particular occurrences at different times, and these instances act as events themselves. Modifications can affect the whole recurring event or only individual instances, and instances that differ from their parent are called exceptions — an exception may have a different summary, a different start time, or additional attendees invited only to that instance.

Outlook and Exchange use the same concept under a different name: an exception added to the series that reschedules a single instance. Microsoft's own developer documentation gives the example of a recurring meeting where "the 7th instance" is rescheduled "to start 2 hours later" without touching any other occurrence. Microsoft Graph exposes this through an exception occurrence type, and in plain iCalendar it's a second VEVENT block carrying the same UID.

Why does syncing a modified occurrence sometimes fail?

Because three different calendar systems encode the same exception differently, and an app that only knows one format silently drops or misreads the other two. A modified single occurrence becomes an exception, a standalone record that overrides the rule for one date while the rest of the series follows the master — but each system encodes this differently: Google creates a separate event with an originalStartTime field, Graph models it as an exception occurrence type, and iCalendar adds a second VEVENT with a RECURRENCE-ID matching the moved instance.

Exceptions are where naive sync code breaks. A calendar app that expands an RRULE into a flat list of dates and times, without checking for a matching exception on each date, will keep showing — and alerting on — the original schedule. The symptom looks identical to a time zone bug or a stale cache, which is why it's easy to confuse with the issue described in calendar reminder wrong time zone fixes, even though the root cause here is a missed exception lookup, not a time zone offset.

Deletions follow the same path but with a status flag instead of new content. Google's API cancels a single instance by fetching it and setting its status to "cancelled" rather than removing it, so the series continues as normal and only the one instance is removed. An alarm app that doesn't check instance status before scheduling will still ring for a meeting that was explicitly cancelled for that week.

What does a correctly handled exception look like in an alarm app?

It means the alarm for that one occurrence moves, or disappears, without touching any other instance in the series. The app has to re-fetch instances on every sync — not just the master event — and match each one against its exception data before scheduling a system alarm through AlarmKit.

To modify a single instance and create an exception, a client application must first retrieve the instance and then update it with an authorized request to the instance edit URL, which means a sync job has to specifically ask for instances, not just the recurring master event. This is distinct from the broader recurrence-vs-single-alarm distinction covered in recurring alarm vs recurring event: what rings — exception handling is about one instance inside an otherwise-normal series, not about whether the alarm itself repeats.

The table below shows what a correct implementation needs to catch, versus what a naive one typically misses.

How does Pealo handle a single modified occurrence?

Pealo re-reads instance-level data from Google Calendar, Outlook, and iCloud on every sync, so an exception to one occurrence — a time change, a cancellation, a retitled meeting — updates that one scheduled alarm without touching the rest of the series. Each alarm it schedules is a real system alarm through AlarmKit, which is what lets it ring through Silent mode on iPhone instead of arriving as a notification that's easy to swipe away.

That matters most for people juggling calendars that generate a lot of one-off changes — recurring 1:1s that get bumped for a conflict, standups that shift by a day. The work and personal calendars, one alarm list setup depends on the same exception data being read correctly across every connected source, not just the one the meeting originated on.