Irregular repeating events in Google Calendar when the pattern breaks

A course runs on Tuesdays and Thursdays, except for the three weeks in the middle of term when it moves to Wednesday. A board meeting is on the first Monday of the month, unless that Monday is a holiday, in which case it slides. A cleaner comes on alternating Fridays, apart from the two weeks in August. None of these fit the repeat menu, and all of them are ordinary.

The repeat setting in Google Calendar answers a narrower question than most people ask of it. It asks for a pattern. A list of dates is not a pattern, and no amount of clicking inside the custom recurrence dialog turns one into the other. What remains is a set of workarounds with genuinely different costs, and choosing between them is easier once it is clear where the boundary sits and why it is there.

The repeat box holds a pattern, not a list

Creating a repeating event in Google Calendar is one menu. Next to "Does not repeat", pick how often the event should repeat and when the repetition should stop. The custom option widens that: an interval, a set of weekdays for weekly repeats, a position in the month for monthly ones, and an end condition.

Everything that dialog can express has the same shape. One rule, applied forward from the first occurrence, generating every date mechanically. That is why "every second Tuesday" works and "every second Tuesday, but the one in April moves to the Wednesday" does not. The first is a rule. The second is a rule plus an exception, and the dialog has no field for an exception.

There is also a documented ceiling. Google's help page on creating a repeating event states that repeating events have a limit of 730 occurrences. A daily event therefore runs out after two years, and anyone who set something to repeat daily forever has an end date whether they chose one or not. For a series built by hand as separate events, the ceiling does not apply, which is occasionally a reason to prefer separate events.

What sits underneath: one rule, plus dates, minus dates

The repeat menu is a front end for the iCalendar format, and the format is more capable than the dialog. Google's own developer documentation for the Calendar API describes the field that holds a repeat as a list of RRULE, EXRULE, RDATE and EXDATE lines as specified in RFC 5545, and notes that the start and end times live in separate fields rather than in that list.

Those four names map exactly onto the problem. RRULE is the rule. RDATE is an explicit list of extra dates. EXDATE is an explicit list of dates to remove. The standard spells out how they combine.

The final recurrence set is generated by gathering all of the start DATE-TIME values generated by any of the specified "RRULE" and "RDATE" properties, and then excluding any start DATE-TIME values specified by "EXDATE" properties. The wording is from section 3.8.5.3 of RFC 5545.

Read that as a recipe and the irregular schedule becomes trivial to describe. The cleaner's visits are an alternating Friday rule, minus two dates in August. The course is a Tuesday and Thursday rule, minus six dates, plus three Wednesdays. One event, one series, no loose copies.

The catch is access. The web interface exposes the RRULE half of this and nothing else. RDATE and EXDATE are reachable by editing an .ics file and importing it, or through the API, and the standard is blunt about one tempting shortcut: a second RRULE on the same event is undefined behaviour, so stacking two rules is not the answer even where a tool lets you type it.

Four ways to build a series that does not follow a rule

Approach	Stays one series	Editable in the browser	Where it hurts
Separate one-off events	No	Yes	Every later change is repeated by hand
Rule plus edited occurrences	Yes	Yes	Exceptions accumulate and get fragile
Several overlapping series	No, one per rule	Yes	Cancelling the whole thing means finding them all
An .ics file with RDATE and EXDATE	Yes	No, rebuilt and reimported	Needs a text editor and one careful test

The second row is what most people end up doing, and for a handful of exceptions it is the right answer. The third row is underrated: a course that meets Tuesdays and Thursdays is two weekly series, not one broken one, and each can be ended or moved independently.

The fourth row is worth the effort exactly once, for the schedules that get published annually. A school timetable, a committee calendar, a delivery rota for the year. Build the file, import it into an empty calendar, check it, then keep the file as the source and rebuild it next year rather than patching the calendar.

Building that file is less daunting than it sounds, because there is no need to write it from memory. Create the regular part of the series in Google Calendar first, export the calendar as an .ics file, and open it in a text editor. The RRULE line Google wrote is then a working example to copy, and adding an RDATE line with the extra dates and an EXDATE line with the ones to drop is editing rather than authoring. Import the result into an empty calendar and count the occurrences on the grid before deleting the original. That last step is not optional: a mistyped date in one of those lines produces a series that is silently wrong rather than an error message, and the grid is the only place the mistake is visible.

The cost of editing single occurrences

Moving one occurrence of a series is two clicks, and it is also the point where a tidy calendar starts to rot. Google's developer documentation attaches an unusually direct warning to it.

Do not modify instances individually when you want to modify the entire recurring event, or "this and following" instances. This creates lots of exceptions that clutter the calendar, slowing down access and sending a high number of change notifications to users.

The mechanism behind that is visible in the data. An occurrence that has been touched stops being generated purely from the rule and becomes a stored exception, carrying its own record of which series it belongs to and what its original start time was. A hundred exceptions on one series is a hundred stored records where there used to be one line of text.

The practical consequences show up as symptoms that look unrelated to recurrence. The series gets slower to open. Guests receive a stream of update notifications for a meeting nobody actually rescheduled. A later "change all events" edit behaves unpredictably, because the fields that were edited on individual occurrences no longer follow the parent.

The discipline that avoids most of this is choosing the right scope at the moment the edit is made. If the new time applies from here onward, choose the option that says so rather than dragging the next six occurrences one at a time. If the pattern itself has changed, end the old series on the last date it was true and start a new one, which leaves a clean history instead of a heap of exceptions.

Skipping dates without breaking the series

Removing a single occurrence is the safest kind of exception, because it does not change any field on the event. Delete the occurrence and choose "This event". The series is intact, and the date is gone.

That handles holidays, closures and the week when everybody is away. It is also the tool for the common case of a monthly meeting that lands on a public holiday: delete that occurrence, then create one standalone event on the replacement date. Two records instead of a moved occurrence, and the series carries on untouched.

What it does not handle is a pattern with a hole in it that keeps coming back, such as a meeting that skips December every year. There is no annual exclusion in the dialog, so the choice is to delete one occurrence each December, or to end the series in November and start a new one in January as a matter of routine.

The patterns that look irregular and are not

Before reaching for a workaround it is worth testing whether the schedule really is irregular, because several shapes that feel impossible are expressible.

Twice a week on fixed days is one rule with two weekdays selected. Every other week is a weekly rule with an interval of two. The last working day of the month, the second Tuesday, the fourth Friday: all of these are positions in the month, and the monthly option covers them. Quarterly is a monthly rule with an interval of three. An event that runs for a fixed number of sessions has an end condition counted in occurrences rather than a date.

The moving holiday case deserves a second look too. A meeting that is always on the first Monday except when that Monday is a public holiday is not one irregular series. It is a regular series with a handful of deletions and a handful of standalone replacements, and the number of those per year is usually three or four. Handling them once a year, when the holiday calendar for the next year is published, takes a few minutes and leaves the series clean.

Genuinely irregular means something narrower: the dates were decided by a person rather than derived from a rule. A tour schedule, a court listing, an exam timetable. For those, a list of separate events is honest and correct, and trying to force them into a recurrence is the actual mistake.

Where a Mac calendar changes the work

Two parts of this get faster outside the browser. The first is writing the rule at all. Typing a sentence such as "every Tuesday 10am standup" or "the second Monday of each month" and having the repeat read out of it removes the trip through the dialog, which matters when a schedule needs six series rather than one. That route is described under Entering events.

The second is the moment of editing. Dragging an occurrence of a repeating event should always ask what the change applies to, because the difference between this one and all of them is the difference between one exception and none. A desktop calendar that prompts at that moment, and that also warns when the new slot collides with something already booked, prevents the two errors that generate the most cleanup later. Both are listed under Features.

What to change first

Test the schedule against the rules before building anything. If it is two weekdays, an interval, or a position in the month, it is one series and the dialog handles it. If it is a list of dates a person chose, build separate events and stop fighting the recurrence engine.

For everything in between, end a series when the pattern changes instead of editing occurrences one by one. Caltimate writes the repeat straight from a typed line on the Mac, which makes running three clean series cheaper than maintaining one broken one.