Guide

Serientermine im Kalender: RRULE erklärt

Ein wöchentliches Standup ist ein Termin in der Datenbank und zweiundfünfzig auf dem Bildschirm. Jedes Kalendersystem überbrückt diese Lücke mit Wiederholungsregeln — RRULE-Strings aus RFC 5545 — und jede Integration stößt irgendwann auf dieselben Fragen: was die Regelsyntax bedeutet, wer die Serie in Instanzen expandiert und was passiert, wenn ein einzelnes Vorkommen verschoben wird. Dieser Guide beantwortet alle drei Fragen, mit den Details zu Google, Microsoft Graph und CalDAV im direkten Vergleich.

Written by Hazik Director of Product Management

Verified — CLI 3.1.16 · last tested June 6, 2026

In diesem Guide verwendete Befehlsreferenzen: nylas calendar events list und nylas calendar events show.

Was ist eine RRULE?

Eine RRULE ist die in RFC 5545 (der iCalendar-Spezifikation) definierte Grammatik für Wiederholungsregeln, die einen sich wiederholenden Zeitplan als einzelnen String beschreibt. Eine Regel ersetzt Hunderte gespeicherter Zeilen: Der Termin existiert einmal, und die Software leitet die Vorkommen ab. Alle drei großen Kalendersysteme speichern RRULE entweder direkt oder übersetzen an ihren Grenzen in beide Richtungen.

Die Grammatik hat einen Pflichtteil, FREQ, und eine Reihe von Modifikatoren. Die 6, die Sie tatsächlich verwenden werden, stehen unten — und eine Einschränkung aus dem RFC ist wichtiger als alle anderen: Die Spezifikation legt fest, dass die Teile UNTIL und COUNT "MUST NOT occur in the same 'recur'". Eine Regel endet auf genau 3 Arten: nie, nach N Vorkommen oder an einem Datum.

TeilBedeutungBeispiel
FREQGrundtakt (erforderlich)FREQ=WEEKLY
INTERVALJede N-te Periode (Standard 1)INTERVAL=2 — zweiwöchentlich
BYDAYWochentag-Selektor; unterstützt OrdinalzahlenBYDAY=MO,WE,FR oder BYDAY=-1FR (letzter Freitag)
BYMONTHDAYSelektor für den Tag im MonatBYMONTHDAY=15
COUNTEnde nach N VorkommenCOUNT=12
UNTILEnde zu einem UTC-ZeitstempelUNTIL=20261231T235959Z
# Every Monday and Wednesday for 12 occurrences
RRULE:FREQ=WEEKLY;BYDAY=MO,WE;COUNT=12

# Biweekly Friday, forever
RRULE:FREQ=WEEKLY;INTERVAL=2;BYDAY=FR

# Last Friday of each month through 2026
RRULE:FREQ=MONTHLY;BYDAY=-1FR;UNTIL=20261231T235959Z

Wer expandiert die Serie in Instanzen?

Die Expansion, also das Umwandeln einer Regel in datierte Vorkommen, findet bei jeder API an einer anderen Stelle statt, und diese Platzierung entscheidet, wie viel Recurrence-Code Sie schreiben. Google expandiert serverseitig auf Anfrage, Graph speichert ein strukturiertes Objekt und stellt eine Instances-Ansicht bereit, und CalDAV liefert die rohe Regel aus und überlässt dem Client die Berechnung. Die 3 Modelle in Kürze:

  • Google Calendar API — übergeben Sie singleEvents=true an events.list, und die Antwort enthält einzelne Instanzen innerhalb Ihres Zeitfensters, jede mit einem recurringEventId. Googles Guide zu wiederkehrenden Terminen behandelt das Master-vs.-Instanz-Modell.
  • Microsoft Graph — Termine speichern ein patternedRecurrence -Objekt mit einem pattern (Takt) und einem range (Grenzen) statt eines rohen RRULE-Strings; die Instanz-Expansion kommt aus der instances-Ansicht des Serien-Masters, begrenzt durch Start- und End-Parameter.
  • CalDAV — der Server gibt das VEVENT mit seiner RRULE unverändert zurück, und der Client expandiert es, einschließlich der Zeitzonenberechnung. Das ohne Hilfe korrekt umzusetzen ist der schwierigste Weg; der Recurrence-Abschnitt von RFC 5545 umfasst nicht ohne Grund Dutzende Seiten.

Die praktische Regel: Wenn Ihre Integration nur "was passiert diese Woche" beantworten muss, bevorzugen Sie eine API (oder ein Tool), die für Sie expandiert. Einen korrekten clientseitigen Expander zu schreiben ist ein Projekt, keine Funktion. Wie sich diese 3 APIs jenseits der Wiederholung unterscheiden (Auth, Verfügbarkeit, Webhooks), zeigt der Kalender-API-Vergleich; diese Seite bleibt beim Recurrence-Problem.

Was passiert, wenn ein Vorkommen verschoben oder abgesagt wird?

Ein geändertes einzelnes Vorkommen wird zur Ausnahme: ein eigenständiger Datensatz, der die Regel für ein Datum überschreibt, während der Rest der Serie dem Master folgt. Jedes System kodiert das anders — Google erstellt einen separaten Termin mit einem originalStartTime-Feld, Graph modelliert es als Occurrence-Typ exception, und iCalendar fügt ein zweites VEVENT mit einer RECURRENCE-ID hinzu, die zur verschobenen Instanz passt.

Ausnahmen sind die Stelle, an der naiver Sync-Code bricht. Zwei Fehlermuster verursachen die meisten Bugs: eine Ausnahme als brandneuen Termin zu behandeln (das Meeting erscheint zweimal: einmal aus der Regel-Expansion, einmal als Override) und eine Serienänderung über eine Ausnahme zu legen (die einmalige Raumänderung des Nutzers wird stillschweigend zurückgesetzt). Sync-Logik muss vor beiden Pfaden auf einen Ausnahme-Marker prüfen — eine Prüfung mit 2 Verzweigungen, die deutlich günstiger ist als das Support-Ticket wegen doppelter Meetings.

Wie liest man Serientermine über das CLI?

Der Befehl nylas calendar events list gibt expandierte Instanzen innerhalb des angeforderten Zeitfensters zurück, sodass eine wöchentliche Serie als datierte Vorkommen erscheint, ohne dass Sie RRULE auf Ihrer Seite parsen müssen. Jede Instanz einer Serie trägt eine master_event_id, die auf den Serien-Master verweist, und die eigene ID der Instanz enthält ihren Vorkommens-Zeitstempel — beides sichtbar in der JSON-Ausgabe.

# Expanded instances for the next 30 days
nylas calendar events list --days 30 --json | jq '.[] | {
  id: .id,
  title: .title,
  master: .master_event_id,
  start: .when.start_time
}'

# Group instances by series to spot every recurring meeting
nylas calendar events list --days 30 --json | jq '
  [.[] | select(.master_event_id != null)]
  | group_by(.master_event_id)
  | map({series: .[0].title, occurrences: length})'

Dieselben 2 Befehle funktionieren mit Google-, Microsoft- und iCloud-Konten, was die API-spezifischen Expansionsunterschiede aus dem vorherigen Abschnitt für Lesepfade beseitigt. Eine ehrliche Einschränkung: Das Erstellen von Terminen mit dem CLI-Befehl calendar events create kennt kein Recurrence-Flag — die Serienerstellung bleibt in der UI oder API Ihres Anbieters, und das CLI übernimmt das Lesen, Filtern und Skripten.

Warum verschieben sich Serientermine rund um die Zeitumstellung?

Ein wöchentliches 9:00-Uhr-Meeting findet um 9:00 Uhr in einer benannten Zeitzone statt, nicht bei einem festen UTC-Offset — zweimal im Jahr verschiebt sich seine UTC-Zeit also um eine Stunde. Regeln, die gegen rohes UTC expandiert werden, driften nach jeder Zeitumstellung; korrekte Expansion löst jedes Vorkommen über die Zeitzonen-Datenbank auf (America/Toronto, nicht UTC-5). Das ist der Hauptgrund, warum clientseitige CalDAV-Expansion schwer ist, und es steckt auch in der Anforderung von RFC 5545, dass UNTIL-Zeitstempel UTC sein müssen, während Terminstarts Zeitzonenreferenzen tragen.

Wenn Sie einen Sync-Bug untersuchen, der im März oder November auftritt, prüfen Sie zuerst, welche Uhr der Expander verwendet hat. Das Instanz-JSON oben enthält start_timezone bei Timespan-Terminen, sodass ein 1-zeiliger jq-Filter für Instanzen, deren Zeitzone von Ihrer Erwartung abweicht, die gedrifteten Serien schnell findet.

Nächste Schritte