ICS in CSV umwandeln

Seit dem Urteil des Bundesarbeitsgerichts vom 13. September 2022 gilt in Deutschland eine grundsätzliche Pflicht zur Arbeitszeiterfassung, und viele Teams behelfen sich vorerst mit dem, was sie bereits haben: dem Kalender. Wie viele Stunden auf ein Projekt entfielen, wie oft ein Meeting tatsächlich stattfand, ob eine Rufbereitschaft dokumentiert ist — das sind Fragen, die ein Kalenderprogramm schlecht beantwortet und eine Tabelle gut.

Genau dafür existiert diese Umwandlung. Diese Einordnung entscheidet auch, welche der folgenden Einschränkungen wirklich zählen: Eine verlorene Terminfarbe ist nichts, ein wiederkehrender Termin, der nur einmal gezählt wird, ist alles — und darum geht es in den nächsten beiden Abschnitten.

Das ist der wichtigste Satz auf dieser Seite, bevor irgendetwas summiert wird. Im Kalenderformat steckt eine Terminserie in einem einzigen Eintrag mit einer Wiederholungsregel — das tägliche Stand-up-Meeting des vergangenen Jahres ist ein VEVENT mit einer RRULE, die „wöchentlich an Werktagen bis zu einem Datum" bedeutet, dazu vielleicht ein paar RDATE-Ergänzungen und EXDATE-Ausnahmen für ausgefallene Tage.

Die hier erzeugten Spalten sind die eigenen Eigenschaften des Termins: Titel, Beginn, Ende, Ort, Beschreibung, Organisator, Status, Kennung, Teilnehmer. RRULE, RDATE und EXDATE gehören nicht dazu, die Serie liefert also genau eine Zeile mit den Zeiten des ersten Vorkommens. Ein Quartal Stand-ups wird zu einer einzigen halbstündigen Zeile. Jede Auswertung, die die Dauerspalte aufsummiert, unterschätzt die tatsächliche Zeit erheblich — in einem üblichen Arbeitskalender oft um den größten Teil davon.

Die Lösung liegt vor der Umwandlung, nicht danach, und ist einfacher, als es klingt. Sowohl Google Kalender als auch Outlook geben beim Exportieren oder Drucken eines Zeitraums die einzelnen Vorkommen statt der Regel aus — der Export „dieses Quartal" liefert also eine Datei, in der jedes Stand-up sein eigener VEVENT ist und damit auch seine eigene Zeile wird.

Fehlt diese Möglichkeit, ist das Auflösen der Serie eher ein Skript als eine Tabellenkalkulationsaufgabe: Pythons icalendar mit dateutil.rrule oder das Node-Paket ical-expander gehen eine Serie zwischen zwei Daten durch und erzeugen die einzelnen Vorkommen. In jedem Fall gilt: die Auflösung geschieht, solange die Datei noch eine ICS ist. Ist sie erst eine Tabelle, ist die Regel weg — die Tabelle hat sie nie getragen.

In dieser Reihenfolge: summary, start, end, location, description, organizer, status, uid, attendees. Jeder Termin erhält alle neun Spalten, leer dort, wo die Eigenschaft fehlt, sodass die Tabelle unabhängig von der Unordnung der Quelle rechteckig bleibt.

Zwei davon lohnen einen zweiten Blick. status unterscheidet bestätigte, vorläufige und abgesagte Termine — abgesagte erzeugen trotzdem eine Zeile, die vor jeder Auswertung herausgefiltert werden sollte, sonst zählt ein abgesagter Ganztagesworkshop als geleistete Zeit mit. Und uid ist eine vom Kalender vergebene, stabile Kennung — der zuverlässigste Weg, Duplikate zu erkennen, wenn sich zwei Exporte überschneiden, deutlich sicherer als ein Abgleich über Titel und Beginn.

Die Zeitstempel werden aus der kompakten Kalenderschreibweise in ISO 8601 umgewandelt, aus 20260301T080000Z wird also 2026-03-01T08:00:00Z, lesbar für jede Tabellenkalkulation. Nicht geschieht dabei irgendeine Umrechnung zwischen Zeitzonen.

Ein Wert in UTC behält sein abschließendes Z. Ein Wert mit TZID-Parameter — etwa DTSTART;TZID=Europe/Berlin:20260301T080000 — ist lokale Zeit dieser Zone und wird unverändert als 2026-03-01T08:00:00 ohne Z und ohne Offset geschrieben. Eine Umrechnung bräuchte eine Zeitzonendatenbank, und UTC anzunehmen würde jeden Termin um eine oder mehrere Stunden verschieben. Das Ergebnis: Eine Spalte, in der manche Zellen ihre Zone nennen und andere nicht, ohne dass die Tabelle sagt, welche Zone die übrigen hatten. Für reine Dauerberechnungen ist das unproblematisch, da Beginn und Ende dieselbe Zone teilen; für einen zeitzonenübergreifenden Vergleich in einem verteilten Team nicht — dort muss die Zone aus der Ursprungsdatei stammen.

Ein ganztägiger Termin wird mit reinen Datumswerten statt Zeitstempeln gespeichert und erscheint als schlichtes 2026-03-01 in Start- und End-Spalte, ohne Uhrzeit. Das ist eindeutig und sortiert sich korrekt.

Die Falle steckt im Format selbst, nicht in der Umwandlung: Bei einem Datumswert ist das Ende exklusiv. Ein eintägiger Termin am 3. wird als beginnend am 3. und endend am 4. gespeichert, ein dreitägiger Workshop ab dem 3. endet entsprechend am 6. Vor jeder Weitergabe an eine Person einen Tag abziehen, und bei jeder Formel zur Dauerberechnung vorsichtig sein — die Arithmetik ist für das Format korrekt und für den Satz, den jemand daraus macht, falsch.

Das Kalenderformat erlaubt es, einen Termin über Beginn und Dauer statt über Beginn und Ende zu beschreiben, und manche Programme nutzen diese Form durchgängig. Nur die End-Eigenschaft wird auf eine Spalte abgebildet, solche Termine kommen also mit gefülltem Beginn und leerem Ende an.

Das fällt eher still auf als auffällig, gerade weil leere Zellen in einer großen Tabelle wie fehlende Angaben aussehen. Ist die End-Spalte auffällig lückenhaft, liegt genau das vor — nach der Quelle sortieren zeigt oft, ob sich die Lücken auf einen einzelnen Exportweg konzentrieren. Der Wert selbst lässt sich nur aus der ursprünglichen ICS-Datei zurückgewinnen, per Skript, nicht per Tabellenkalkulation.

Eine Einladung speichert einen Teilnehmer als Adresse im Wert und als Anzeigenamen in einem Parameter. Behalten wird die lesbare Hälfte, die Zelle enthält also „Anna Weber", wo die Einladung einen Klarnamen mitführte, und [email protected], wo nicht. Mehrere Teilnehmer werden mit Semikolon und Leerzeichen in einer einzigen Zelle zusammengefasst. Der Organisator erhält dieselbe Behandlung in einer eigenen Spalte.

Das ist eine bewusste Entscheidung gegen erfundene Spalten wie attendee1 bis attendee9, die beim zehnten Teilnehmer abgeschnitten wären und für alle anderen fast leer blieben. Das Zählen der Teilnehmer wird dadurch zu einer Formel auf der Zelle statt zu einer Spaltenzählung; das Aufteilen auf einzelne Zeilen ist ein Power-Query-Schritt oder ein kurzes Skript, falls eine Zeile pro Person gebraucht wird.

Das Kalenderformat transportiert mehr als Termine. Aufgaben sind VTODO, Journaleinträge VJOURNAL, Frei-Belegt-Blöcke VFREEBUSY, und Erinnerungen stecken als VALARM innerhalb von Terminen. Gelesen wird hier ausschließlich VEVENT.

Eine Datei, die nur Aufgaben enthält, endet deshalb mit der zutreffenden Meldung, dass keine Kalendereinträge gefunden wurden — ein Export aus einer Erinnerungs-App ist eben kein Terminkalender, auch wenn die Dateiendung gleich aussieht. Erinnerungen, Anhänge und der individuelle Antwortstatus je Teilnehmer entfallen aus demselben Grund wie die Wiederholungsregel: Eine Tabelle hat keine Form dafür, und erfundene Spalten wären schlechter als das Weglassen.

Importieren statt einfach Öffnen. In Excel über Daten, dann Aus Text/CSV, und die Start- und End-Spalten dabei explizit auf Text setzen — sonst interpretiert Excel die Werte neu, entfernt die Zeitzonenangabe, formatiert nach der Ländereinstellung des Rechners um und macht aus einem sortierbaren ISO-String etwas anderes. Die Kennungsspalte sollte ebenfalls Text bleiben.

Beschreibungen verdienen einen zweiten Blick. Terminbeschreibungen enthalten häufig Kommas, Anführungszeichen und echte Zeilenumbrüche — eine eingefügte Tagesordnung, Einwahldaten —, und alle drei werden korrekt behandelt, indem der Wert in Anführungszeichen gesetzt und interne Anführungszeichen verdoppelt werden, wie es RFC 4180 vorsieht und jeder ordentliche Importer liest. Ein naives Aufteilen an Kommas in einer Shell-Pipeline tut das nicht — ein echter CSV-Leser oder die Umwandlung nach TSV ist hier der sicherere Weg.

Exportiert ein Team mehrere Kalender einzeln — pro Person, pro Projekt, pro Raum —, lassen sich alle ICS-Dateien gemeinsam ablegen. Jede wird für sich in eine eigene CSV umgewandelt, im Browser, ohne dass eine der Dateien irgendwohin übertragen wird, und alle kommen gesammelt als ein ZIP zurück.

Für eine Auswertung über mehrere Kalender hinweg lohnt es sich, vor dem Zusammenführen eine Spalte mit dem ursprünglichen Dateinamen zu ergänzen, denn die uid ist nur innerhalb eines Kalenders garantiert eindeutig — zwei unabhängige Kalender können rein zufällig identische Kennungen verwenden, wenn sie von unterschiedlicher Software stammen.

Wer statt eines Kalenders eine Kontaktliste hat, findet auf dieser Website eine eigene VCF-zu-CSV-Seite, und die Probleme dort liegen anders. Bei Kontakten sind es vor allem Felder mit mehreren Werten — mehrere Telefonnummern, mehrere Adressen an einer Person —, die Spalten füllen; bei Terminen ist es fast ausschließlich die Wiederholungsregel, die eine Zeile zu wenig aussagt.

Beide Umwandlungen laufen aus demselben Grund nur in eine Richtung: Ein Kalendereintrag braucht eine Zeitzone, eine eindeutige Kennung und eine Dauer, die eine flache Tabelle nicht von sich aus liefert, und diese Angaben aus einer CSV zu erraten, würde Termine erzeugen, die beim Import korrekt aussehen und es nicht sind.