Was ist eine ICS-Datei? Die Kalendereinladung, aufgeklappt

Eine ICS-Datei ist ein Kalendertermin in reinem Text. Sie kommt als E-Mail-Anhang, steckt hinter jedem „Zum Kalender hinzufügen”-Knopf und ist der Grund, warum eine Einladung überhaupt in Ihrem Kalender erscheinen kann, obwohl der Absender völlig andere Software nutzt.

Benennen Sie eine in .txt um und öffnen Sie sie — der Inhalt ist lesbar, und fast jedes Kalenderproblem ist darin sichtbar.

Wie es innen aussieht

BEGIN:VCALENDAR
METHOD:REQUEST
BEGIN:VEVENT
UID:[email protected]
DTSTART;TZID=Europe/Berlin:20261110T140000
DTEND;TZID=Europe/Berlin:20261110T150000
SUMMARY:Projektbesprechung
LOCATION:Raum 3
END:VEVENT
END:VCALENDAR

UID: warum Verschieben keinen Doppeleintrag erzeugt

Jeder Termin trägt eine UID — eine eindeutige Kennung, die über das ganze Leben dieses Termins gleich bleibt.

Wird ein Meeting verlegt, verschickt die Software der Organisatorin eine neue ICS-Datei mit derselben UID und höherer Sequenznummer. Ihr Kalender erkennt denselben Termin und aktualisiert den vorhandenen Eintrag, statt einen weiteren anzulegen.

Genau deshalb entstehen doppelte Termine. Erzeugt ein Werkzeug bei jedem Export eine frische UID — manche Buchungssysteme und Newsletter-Links tun das — kommt jede Aktualisierung als brandneuer Termin an, und Sie haben drei Kopien eines Meetings. Die Dubletten sind kein Fehler Ihres Kalenders; ihm wurde gesagt, es seien verschiedene Termine.

METHOD: warum manche Einladungen Antwortknöpfe haben

• REQUEST — eine Einladung. Ihre Software zeigt Zusagen / Absagen / Vorläufig und schickt Ihre Antwort zurück.
• PUBLISH — eine Ankündigung. Sie fügt den Termin nur ein; es gibt niemanden zum Antworten.
• CANCEL — entfernt den Termin.
• REPLY — jemandes Antwort auf eine Einladung.

Kommt eine Einladung also als schlichter Anhang ohne Antwortknöpfe, ist es meist eine PUBLISH-Datei oder ein REQUEST, der beim Weiterleiten seinen Einladungsstatus verlor. Ihn anzunehmen trägt den Termin ein, sagt der Organisatorin aber nichts — so gilt jemand als „nicht geantwortet” bei einem Meeting, zu dem er kommen will.

Zeitzonen: die Ursache fast jeder falschen Uhrzeit

• Mit Zeitzone: DTSTART;TZID=Europe/Berlin:20261110T140000 — vierzehn Uhr in Berlin, für alle anderen korrekt umgerechnet. Das wollen Sie.
• In UTC: DTSTART:20261110T130000Z — das abschließende Z heißt UTC, jeder Kalender rechnet korrekt um. Ebenfalls gut.
• Schwebend, ohne Zone: DTSTART:20261110T140000 — vierzehn Uhr, wo auch immer die lesende Person ist. Für eine persönliche Erinnerung richtig. Für ein Meeting zwischen Städten eine Katastrophe: Alle sehen 14 Uhr in ihrer eigenen Zone, und niemand trifft sich.

Landet ein Meeting um Stunden daneben im Kalender, liegt es fast immer daran. Die zweite häufige Spielart ist ein Export aus einem System, dessen eigene Zeitzoneneinstellung falsch war — dann ist die Datei in sich stimmig und durchgängig falsch.

Ganztägige Termine haben ihre eigene Fassung davon. Ein korrekter ganztägiger Termin wird als Datum ganz ohne Uhrzeit geschrieben (DTSTART;VALUE=DATE:20261110). Als Uhrzeit geschrieben — Mitternacht in irgendeiner Zone — rutscht er für weit östlich oder westlich Sitzende auf den Vor- oder Folgetag. Deshalb landet ein Geburtstag manchmal am falschen Datum.

Serientermine und das Ändern eines einzelnen

Ein wöchentliches Meeting wird nicht als zweiundfünfzig Termine gespeichert. Es ist ein Termin plus eine Regel:

RRULE:FREQ=WEEKLY;BYDAY=MO;COUNT=52

Der Kalender erzeugt die Vorkommen aus dieser Regel. Zwei weitere Zeilen behandeln die Ausnahmen, die echte Zeitpläne immer hervorbringen: EXDATE löscht ein Vorkommen, und ein eigener Termin mit RECURRENCE-ID überschreibt eines — der Mechanismus hinter „diese Woche auf Dienstag verschoben”, ohne die Serie zu stören.

Die Unterstützung dieser Ausnahmen schwankt zwischen Programmen, weshalb ein geändertes Vorkommen beim Wechsel zwischen Systemen manchmal zurückspringt oder doppelt erscheint.

Importieren oder Abonnieren: die wichtigste Unterscheidung

Importieren kopiert die Termine einmal in Ihren Kalender. Sie gehören Ihnen, Sie können sie bearbeiten, und sie sind eingefroren. Ändert sich die Quelle, passiert nichts — Ihre Kopie bleibt, wie sie war.

Abonnieren einer ICS-Adresse behält eine Verbindung. Ihr Kalender holt die Datei regelmäßig neu, und Änderungen an der Quelle erscheinen. Bearbeiten können Sie die Termine nicht, denn sie gehören Ihnen nicht wirklich.

Fast alle tappen mindestens einmal hinein: Ein Stundenplan, ein Spielplan oder ein geteilter Teamkalender wird importiert, die Organisation ändert danach mehrere Termine, und der Kalender zeigt still weiter die alten. Nichts warnt Sie, denn aus Sicht des Kalenders ist nichts schiefgegangen.

Die Regel ist einfach. Ändert sich die Quelle weiter, abonnieren. Ist es ein einmaliger Termin, importieren. Abo-Links sehen meist aus wie eine URL, die auf .ics endet, manchmal beginnend mit webcal:// — dasselbe, nur an eine Kalender-App adressiert.

Ein Vorbehalt: Abonnierte Kalender aktualisieren nach dem eigenen Zeitplan der Anwendung, was mehrere Stunden oder gar einen Tag dauern kann.

Kurzübersicht

• Eine Textdatei, die Termine beschreibt — öffnen und lesen
• Die UID identifiziert einen Termin; eine geänderte UID erklärt Dubletten
• METHOD:REQUEST bringt Antwortknöpfe; PUBLISH trägt nur ein
• Zeiten brauchen TZID oder ein abschließendes Z — eine schwebende Zeit heißt „lokal, wo immer Sie sind”
• Ganztägige Termine müssen ein Datum sein, nicht Mitternacht, sonst rutschen sie einen Tag
• RRULE erzeugt Serien; EXDATE und RECURRENCE-ID regeln die Ausnahmen
• Import = eingefrorene Kopie. Abo = aktualisiert sich. Daran scheitern alle einmal