Dieselbe .ics-Datei kann fünf verschiedene Zeiten meinen

Warum die Datei eine Zone nennt statt eines Versatzes

Ein +02:00 hinzuschreiben würde die Besprechung auf eine Zahl festnageln, die zweimal im Jahr aufhört zu stimmen. Ein wöchentlicher Termin um 14:00 in Paris ist im September +02:00 und im November +01:00, und der Sinn eines Serientermins ist, dass er auf beiden Seiten der Umstellung um zwei Uhr nachmittags bleibt. Europe/Paris zu nennen sagt, welches Regelwerk gilt; der Versatz wird danach, Datum für Datum, in einer Zonendatenbank nachgeschlagen, die aktualisiert wird, sobald ein Land seine Uhren verstellt.

Deshalb ist die Umrechnung einer TZID-Zeit nach UTC auch keine Kopfrechenaufgabe, und deshalb sollte ein Werkzeug ohne Zonendatenbank es gar nicht erst versuchen. Namen und Uhrzeit genau so zu behalten, wie die Datei sie geschrieben hat, verliert nichts; sie durch einen aus der falschen Zone berechneten Zeitpunkt zu ersetzen schon — und das ist die Sorte Fehler, die auf dem Bildschirm normal aussieht, bis jemand eine Stunde zu spät in eine Videokonferenz kommt.

Der ganztägige Termin, der gar keine Zeit ist

Ein Geburtstag, ein Feiertag oder ein freier Tag wird als DTSTART;VALUE=DATE:20261225 geschrieben — acht Ziffern, keine Uhrzeit, und der Parameter, der das sagt. Es meint den ganzen 25. Dezember, wo immer der Lesende ist, was für Weihnachten genau richtig und als Zeitpunkt falsch wäre. Schreibt man es als Datum-Zeit um, wird daraus Mitternacht UTC — in Europa noch der 25., westlich von Greenwich schon der 24. Der Marker VALUE=DATE wird hier weitergereicht, statt in eine Stunde aufgelöst zu werden.

Was zu prüfen ist, bevor man einem importierten Kalender traut

Öffne die Datei im Betrachter und sieh dir einen Termin an, dessen wirkliche Zeit du kennst. Stimmt sie dort, stimmt die Datei, und jede spätere Abweichung kommt aus der Anwendung, in die du importiert hast. Drei Gewohnheiten decken fast alles ab: die Z-Form bevorzugen, wenn du einen Kalender veröffentlichst, den andere abonnieren; TZID behalten, wenn du deinen eigenen Kalender zwischen Anwendungen bewegst; und nie eine Anfangszeit von Hand im Texteditor ändern, ohne nachzusehen, in welcher der drei Formen die Zeile steht.

Häufige Fragen

Meine importierten Termine sind alle um ein bis zwei Stunden verschoben. Was ist passiert?

Eine gleichbleibende Verschiebung über alle Termine ist die Signatur einer weggeworfenen und ersetzten Zone. Öffne die ursprüngliche .ics im Betrachter: Sehen die Anfangszeiten dort richtig aus, hat die Datei ihre Zone behalten und die Anwendung, in die du importiert hast, wendet eine andere an — prüfe deren Kalender-Zeitzoneneinstellung, die von der des Betriebssystems getrennt ist. Eine Verschiebung, die je Termin schwankt, ist ein anderes Problem, meist eine Mischung aus Z- und schwebenden Zeiten in einer Datei.

Welche Form soll ich beim Veröffentlichen eines Kalenders nehmen?

Z für alles mit festem Zeitpunkt — ein Webinar, ein Spiel, eine Frist —, denn es kann nicht falsch gelesen werden und braucht am anderen Ende keine Zonendatenbank. TZID für einen Kalender, den Leute örtlich leben, etwa einen Stundenplan oder Bürozeiten, wo die Uhrzeit über die Zeitumstellung hinweg stehen bleiben muss. VALUE=DATE für ganze Tage. Schwebende Zeiten nur, wenn du wirklich überall Ortszeit meinst — praktisch also Silvester und kaum sonst etwas.

Ändert der Betrachter meine Datei?

Nein. Er liest die Datei in deinem Browser und zeigt, was darin steht; die Datei auf der Festplatte bleibt unangetastet, und nichts wird irgendwohin geschickt. Genau darum lohnt das Hinschauen vor dem Umwandeln: Du kannst einen Streit über eine Anfangszeit klären, ohne dich auf irgendetwas festzulegen.