iCalendar-Einladungen: UID, SEQUENCE und korrekte Zeitzonen

Worum es geht

iCalendar (RFC 5545, Medientyp text/calendar) beschreibt Ereignisse als VEVENT-Komponenten innerhalb eines VCALENDAR. iTIP (RFC 5546) definiert, wie sie ausgetauscht werden: METHOD:REQUEST von der Organisatorin, METHOD:REPLY von Teilnehmenden mit einem PARTSTAT (angenommen, abgelehnt, vorläufig), METHOD:CANCEL zum Zurückziehen. Ein Ereignis wird über alle Nachrichten hinweg über UID identifiziert; eine Überarbeitung über SEQUENCE, das die Organisatorin erhöhen muss, wenn sich DTSTART, DTEND, DURATION, RRULE und ähnliche Eigenschaften ändern. Zeiten treten in drei Formen auf: UTC (20260916T090000Z), lokale Zeit mit einem TZID-Parameter, der auf eine VTIMEZONE-Komponente im selben Objekt verweist (DTSTART;TZID=Europe/Zurich:20260916T110000), und frei schwebende Zeit ohne beides, was "11:00 wo auch immer die Leserin ist" bedeutet. RFC 5545 verlangt eine VTIMEZONE für jede verwendete TZID und warnt, dass ihr Fehlen zu widersprüchlicher Auslegung der lokalen Zeit führt.

Warum es wichtig ist

Eine Einladung, die nach einer Sommerzeitumstellung eine Stunde daneben liegt, oder die bei jeder Aktualisierung ein Duplikat erzeugt, ist schlimmer als keine. Kalender sind eine der Stellen, an denen "UTC speichern" nicht genügt: Ein wöchentlicher 09:00-Termin in Zürich muss über die März- und Oktoberumstellung hinweg bei 09:00 Lokalzeit bleiben, was nur eine zonengebundene lokale Zeit ausdrückt.

So wird es angewendet

• Eine stabile UID pro Ereignis erzeugen, speichern, bei jeder Aktualisierung und Absage wiederverwenden und SEQUENCE bei jeder inhaltlichen Änderung erhöhen; DTSTAMP ist der Nachrichtenzeitpunkt, nicht der Überarbeitungszähler.
• TZID mit IANA-Zonennamen verwenden und eine korrekte VTIMEZONE (mit STANDARD- und DAYLIGHT-Regeln) aus einer gepflegten Bibliothek einbetten. UTC für einmalige Ereignisse mit Teilnehmenden in vielen Zonen verwenden, frei schwebende Zeit nur für Dinge, die tatsächlich der Wanduhr der Leserin folgen; ganztägige Ereignisse verwenden einen DATE-Wert (DTSTART;VALUE=DATE:20260916) statt einer frei schwebenden Mitternacht.
• Bei wiederkehrenden Ereignissen RFC 5545 folgen: Hat DTSTART eine TZID, muss der UNTIL-Teil der Regel in UTC vorliegen. Einzelne Vorkommen mit RECURRENCE-ID ändern, statt die Serie zu bearbeiten.
• Einladungen als text/calendar-Teil mit gesetztem method-Parameter senden (method=REQUEST) und dasselbe Objekt zusätzlich als .ics-Anhang beifügen, für Clients, die den Parameter ignorieren.
• Mit mindestens zwei Client-Familien über eine Sommerzeitgrenze hinweg testen, einschliesslich einer Aktualisierung und einer Absage.

Stolpersteine

Eine neue UID bei jeder Aktualisierung (Duplikate). Zonennamen, die keine IANA-Bezeichner sind und die andere Clients nicht zuordnen können. Absagen mit STATUS:CANCELLED, aber ohne METHOD:CANCEL. Ganztägige Ereignisse, die als Mitternacht-zu-Mitternacht-UTC gesendet werden und dadurch in anderen Zonen um einen Tag verschieben. Ein CANCEL senden, ohne SEQUENCE zu erhöhen, was RFC 5546 verlangt.