Repetition is where calendars get genuinely complicated: a weekly meeting is not one event but a rule for generating them, and every exception you make is stored separately from the rule. Most confusion is really a question about which of the two you just edited.
A recurring event is a rule that generates occurrences — every Tuesday, the first Monday of the month — rather than a set of copies. Editing the rule changes every future occurrence; editing one occurrence creates an exception to it.
RRULE is the iCalendar field describing how an event repeats, such as FREQ=WEEKLY;BYDAY=TU;INTERVAL=2 for every other Tuesday. Every calendar application reads it, which is why repeating events survive being moved between systems.
That occurrence is detached from the series and stored as an exception. Later changes to the series will not touch it, which is the usual reason one week of a weekly meeting stubbornly stays at the old time.
Use 'this and following', which ends the original rule at that date and starts a new one. Editing the whole series instead rewrites history and makes past meetings appear at times they did not happen.
Because the edit applied to the whole series rather than from a date. The record of what actually happened is usually worth more than the tidiness of one rule, so prefer 'this and following'.
It means an interval of two weeks from the start date, not the even-numbered weeks of the year. Two people with fortnightly meetings starting a week apart will never agree on which week is 'on'.
Use a rule with a negative position — BYDAY=-1FR — rather than picking the 25th to 31st by hand. The rule stays correct in every month length.
It is skipped in most systems, rather than moved to the 28th. If it must happen every month, anchor it to the last day or to a weekday position instead of to a number.
Yes, and most do. An open-ended rule is fine for a genuine standing commitment and a slow leak for anything else, which is why some teams cap recurring meetings at a quarter and renew deliberately.
Delete that occurrence only; it is stored as an exclusion from the rule. The series continues, and the cancelled date stays cancelled even if the series is later edited.
A recurring event is one block that repeats. A routine is a sequence of steps you repeat — a morning routine with six things in it — which is why routines are usually tracked as completed or not, and meetings are not.
Yes, if it needs a time, and as a routine rather than an event if it has steps. The value is not the reminder but the space: an hour that is already claimed cannot be booked by somebody else.
It keeps its local time in its own zone and shifts by an hour for everyone in a zone that did not change. That is correct — the alternative would move it for its owner, who chose the time.
Decide again rather than letting it drift: the time that suited both of you may now suit neither. Changing the series anchor is a deliberate act and worth a conversation rather than a silent edit.
Yes, by deleting the individual occurrences. Doing it in advance is far better than a room of people discovering it on the day.
An exception is a single occurrence that differs from the rule, either moved, changed or deleted. Calendars store exceptions alongside the rule, which is why an exported .ics of a series can be surprisingly long.
Usually a zone mismatch in the rule: a series anchored to a floating time will be interpreted in each reader's own zone. Anchoring the series to a real zone fixes it everywhere at once.
Quarterly is a workable rhythm. The question worth asking is not 'is this useful' but 'would we create it today', which gets a much more honest answer.
A standing meeting is a recurring meeting held whether or not there is an agenda. They are worth keeping when the value is the relationship and worth cancelling when the value was the agenda.
Not within one rule — a series has one duration. Varying lengths means either separate events or an exception per occurrence, which is usually a sign the series is doing two jobs.
Use a rule that names the days — Monday to Friday — rather than a daily rule you cancel twice a week. Cancelling generates exceptions forever; naming the days generates none.
Record completion per occurrence rather than per rule, so a missed morning shows as a gap rather than erasing the routine. A streak is only meaningful if the misses are recorded too.
Mark them busy if you genuinely will not be interrupted, and free if you would take a meeting instead. Marking everything busy makes your calendar unbookable and gets you booked over anyway.
Something has to give, and the useful behaviour is to be told before it is booked rather than after. A calendar that offers to move the routine, rather than silently overlapping it, is doing the job.
Yes — name the specific days in the rule rather than using a daily rule with exclusions. BYDAY=MO,TU,WE,FR is one rule; daily-minus-Thursday is fifty-two exceptions a year.
Edit the series rather than each occurrence, and choose 'this and following' so the history stays accurate. Existing exceptions will keep their own times and may need adjusting individually.
Because two systems generated occurrences from the same rule and neither recognised the other's copies. It is usually caused by importing an .ics of a series that is already subscribed.
Every four weeks is thirteen times a year and always the same weekday; monthly is twelve times and drifts across weekdays. Teams that want a consistent weekday should use the four-week rule.
Not directly in most systems — you delete the occurrences in that range, or end the series and start a new one afterwards. Ending and restarting is tidier if the pause is long.
Keep it. The record of which occurrences happened, moved or were cancelled is the only evidence of how a commitment actually went, and it costs almost nothing to store.
Daykite is a calendar that holds meetings, routines, tasks and goals together, with an assistant that shows you every change before it makes it. Free for one person.