Probleme mit Zeitzonen im Kalender sehen oft ähnlich aus. Bei Ihnen steht der Termin um 09:00, bei der eingeladenen Person um 15:00. Das kann ein normaler Unterschied der Ortszeiten sein. Es kann aber auch bedeuten, dass die Einladungen tatsächlich verschiedene Startzeitpunkte nennen. Oder der Termin stimmt wochenlang und verschiebt sich nach der Zeitumstellung plötzlich um eine Stunde. Oder die Erinnerung kommt, während Sie schlafen.
Die Ursache liegt häufig nicht in der Anzeige. Gespeichert wurde schlicht „9 Uhr“, ohne festzuhalten, in welcher Zeitzone diese 9 Uhr gemeint waren. Die nachgelagerten Komponenten ergänzen die fehlende Information selbst und treffen dabei unterschiedliche Annahmen.
Hier erfahren Sie, wie Kalender Zeitzonen abbilden, weshalb ein Fehler erst Wochen später auffallen kann und was sich ändert, wenn ein Ereignis seine Zeitzone mitführt.
Das Problem einer Uhrzeit ohne Zeitzone
Angenommen, ein Kalender speichert den Beginn als 2026-09-14 09:00 und sonst nichts. Für einen gemeinsamen Termin ist diese Angabe mehrdeutig. Verschiedene Komponenten können sie unterschiedlich auslegen.
Das Browserformular übermittelt die eingegebene Uhrzeit. Ein CalDAV-Client liefert zusätzlich die Zeitzonenkennung. Ignoriert der Server diese, bleiben nur die Werte der lokalen Uhr. Beim Export könnte diese Zeit fälschlich als UTC gekennzeichnet werden, weil das Format eine bestimmte Darstellung erwartet. Der Erinnerungsdienst vergleicht den gespeicherten Wert unterdessen mit der aktuellen UTC-Zeit.
Vier Komponenten, vier Auslegungen derselben Angabe. Wenn alle UTC verwenden, fällt der Fehler möglicherweise nicht auf. Sobald eine Person aus Berlin hinzukommt, werden manche Termine anders verarbeitet, ohne dass eine Fehlermeldung erscheint.
Bei Tests in nur einer Zeitzone lässt sich dieser Fehler leicht übersehen. Tests mit mehreren Regionen helfen, ihn frühzeitig zu entdecken. Andernfalls zeigt er sich erst auf Reisen, bei der Zeitumstellung oder nach der ersten Einladung an jemanden in einer anderen Zeitzone.
Drei Arten der Zeitangabe im Kalender
Der iCalendar-Standard, auf dem der Ereignisaustausch vieler Kalender beruht, unterscheidet mehrere Darstellungen von Datum und Uhrzeit. Für Ereignisse mit einer konkreten Uhrzeit sind diese Varianten wichtig.| Art | Beispiel | Bedeutung | Geeignet für |
|---|---|---|---|
| UTC | 20260914T070000Z | Ein bestimmter Zeitpunkt, überall derselbe | Besprechungen mit Teilnehmern aus verschiedenen Regionen |
| Uhrzeit mit Zeitzone | TZID=Europe/Berlin:20260914T090000 | 9 Uhr in Berlin, für andere Orte umgerechnet | Ein Ereignis mit festem Veranstaltungsort |
| Lokale Zeit ohne Zeitzone | 20260914T090000 | 9 Uhr nach der jeweiligen lokalen Uhr | Persönliche Erinnerungen, die der Ortszeit folgen sollen |
Eine solche gleitende Zeitangabe, auch „floating time“ genannt, ist zulässig, wenn genau dieses Verhalten gewünscht ist. Ein Geburtstag, etwa am 14., wird jedoch normalerweise als Datum dargestellt, nicht als Uhrzeit ohne Zeitzone. Bei einer gemeinsamen Besprechung können identische Ortszeiten unterschiedliche tatsächliche Zeitpunkte bedeuten.
Ganztägige Ereignisse werden als Datumswerte gespeichert, ohne Umrechnung zwischen Zeitzonen. Würde man einen Feiertag in einen UTC-Zeitpunkt umwandeln und zurückrechnen, könnte er westlich von Greenwich am Vorabend erscheinen. Ein Datum sollte deshalb nicht wie die Startzeit einer Besprechung behandelt werden.
Warum die Zeitumstellung Fehler aufdeckt
Zeitzonen wären einfacher zu handhaben, wenn ihr Abstand zu UTC konstant bliebe. In vielen Regionen ändert er sich jedoch. Die Umstellung bringt Fehler ans Licht, die zuvor unbemerkt geblieben sind.
Berlin verwendet im Winter UTC+1 und im Sommer UTC+2. Wird ein Serientermin nach einer festen UTC-Uhrzeit berechnet, verschiebt er sich nach der Umstellung auf der lokalen Uhr. Der Zeitpunkt ist eindeutig, aber es ist nicht mehr die Besprechung um 9 Uhr. Damit eine Serie mit Europe/Berlin weiterhin um 9 Uhr stattfindet, müssen auch ihre Wiederholungen in dieser Zeitzone berechnet werden. Den Namen der Zeitzone zu speichern reicht dafür nicht aus.
Über Landesgrenzen hinweg wird es komplizierter: Europa und Nordamerika stellen ihre Uhren an unterschiedlichen Tagen um. Dazwischen weicht der übliche Zeitunterschied zwischen London und New York um eine Stunde ab. Wie lange dieser Zeitraum dauert, hängt von Jahreszeit und Jahr ab; er ist nicht immer gleich lang. Ein Termin kann sich deshalb für eine Seite vorübergehend auf der lokalen Uhr verschieben, obwohl der Kalender korrekt arbeitet.
Eine andere Standardzeitzone löst diesen Unterschied nicht. „Derselbe Zeitpunkt“ und „Dieselbe Ortszeit“ sind unterschiedliche Anforderungen. Für eine Serie muss feststehen, welches Verhalten gewünscht ist und ob Wiederholungsberechnung sowie Austausch mit den Clients es erhalten.
UTC und Zeitzone gemeinsam speichern
Für ein Ereignis mit konkreter Uhrzeit sollten beide Informationen gespeichert werden: der genaue UTC-Zeitpunkt und die Zeitzone, in der die lokale Uhrzeit eingegeben wurde. Bei einer Serie kommt die Berechnung der Wiederholungen hinzu.
UTC ermöglicht eindeutige Vergleiche, Sortierungen und Überschneidungsprüfungen. Die Zeitzone erklärt die ursprünglich gemeinte Ortszeit. Das gespeicherte Feld garantiert aber nicht, dass jeder Export alle Eigenschaften einer Serie überträgt. Prüfen Sie das erzeugte Format und die Verarbeitung durch den Client gesondert.
In der Praxis bedeutet das:
- Beim Erstellen im Webmail wird die Browserzeitzone zusammen mit der eingegebenen Uhrzeit übertragen. Der Server rechnet die Zeit in UTC um und speichert die Zeitzone. Ist der Browser auf Berlin eingestellt, wird Berlin hinterlegt.
- Beim Anzeigen an einem anderen Ort wird UTC in die lokale Browserzeit umgerechnet. Am Datum des Beispiels sieht Berlin 09:00 und San Francisco 00:00. Beide Angaben bezeichnen denselben Zeitpunkt; zu anderen Jahreszeiten können die Abstände anders ausfallen.
- Erinnerungen haben einen eindeutigen Zeitpunkt für den Vergleich. Die Zeitzone verursacht dann nicht mehr diese Mehrdeutigkeit. Der Versand hängt weiterhin vom Aufgabenplaner und den Benachrichtigungskanälen ab.
- Beim Bearbeiten erscheint die Uhrzeit in der Zeitzone des aktuellen Browsers, nicht unbedingt in der ursprünglichen Ereigniszeitzone. Prüfen Sie vor dem Speichern Uhrzeit und Geräteeinstellungen, besonders nach einer Reise.
Was mit älteren Ereignissen passiert
Bei älteren Ereignissen fehlt möglicherweise die gespeicherte Zeitzone. Sie werden nicht automatisch neu interpretiert: Die Weboberfläche behält ihre bisherige Darstellung bei. So verschieben sich bestehende Termine nicht unvermittelt.
Das ist beabsichtigt. Nachträglich eine Zeitzone zuzuweisen bedeutet, sie zu erraten. Eine falsche Annahme verlegt Termine ohne Rücksprache. Wenn ein Ereignis seit zwei Jahren 14:00 anzeigt, sollte eine automatische Korrektur daraus keine andere Uhrzeit machen. Klären Sie bei einer manuellen Prüfung zuerst, was diese 14:00 ursprünglich bedeuteten.
Beim Bearbeiten lässt sich einem alten Ereignis eine Zeitzone hinzufügen. Webmail überträgt beim Speichern eines Ereignisses mit Uhrzeit die Browserzeitzone. Prüfen Sie deshalb zuerst Ortszeit und Geräteeinstellungen. Eine reine Beschreibungsänderung über die API ohne Zeitzonenparameter ergänzt diese Information nicht. Unveränderte Einträge behalten ihr bisheriges Verhalten.
Wenn ein älterer Serientermin für Teilnehmer im Ausland falsch erscheint, prüfen Sie die ursprüngliche Uhrzeit und Zeitzone und speichern Sie die Korrektur. Kontrollieren Sie anschließend die Wiederholungen vor und nach der Zeitumstellung. Erneutes Speichern allein garantiert keine korrekte Berechnung der gesamten Serie.
CalDAV, ICS und andere Kalender
Ein Kalender sollte nicht nur in seiner Weboberfläche funktionieren. Apple Calendar, Thunderbird und kompatible mobile Apps können sich über CalDAV verbinden. Dass Google Calendar auf einem Gerät vorhanden ist, bedeutet aber nicht, dass sich damit jeder beliebige CalDAV-Server anbinden lässt. Prüfen Sie den Integrationsweg und seine Kompatibilität.
Bei einem per CalDAV übertragenen Ereignis nutzt der Server die Zeitzonenkennung, um den entsprechenden UTC-Zeitpunkt zu speichern. Das empfangene Kalenderdokument kann unverändert zurückgegeben werden; für im Webmail erstellte Ereignisse erzeugt der Server UTC-Werte. Antworten haben daher nicht immer dieselbe Darstellung. Ganztägige Ereignisse werden als Datumswerte ausgetauscht. Bei Serien sollten Sie zusätzlich prüfen, ob die lokale Uhrzeit der Wiederholungen beim Austausch erhalten bleibt.
Kompatible Clients können denselben Zeitpunkt anzeigen: etwa bei einem Ereignis, das auf einem iPhone in Berlin erstellt, im Webmail auf einem Laptop in Lissabon bearbeitet und in Thunderbird in New York geöffnet wird. Die Ortszeiten unterscheiden sich dabei. Voraussetzung sind korrekte Client- und Geräteeinstellungen; die Zeitzonennamen stammen aus der IANA-Zeitzonendatenbank.
Einrichtungsanleitungen gibt es für Apple Calendar unter macOS, iPhone und iPad, Android mit DAVx⁵ und Thunderbird. Outlook benötigt für CalDAV in der Regel eine Erweiterung eines Drittanbieters. Versionsabhängige Einschränkungen stehen in der Outlook-Anleitung.
So vermeiden Sie Zeitzonenfehler
Nennen Sie bei internationalen Besprechungen die Zeitzone im Titel. „Wöchentliche Abstimmung (09:00 CET)“ kann helfen, wenn ein Mailprogramm die Einladung falsch darstellt. CET bezeichnet allerdings die Winterzeit; im Sommer gilt in Berlin CEST. Verwenden Sie die zum Termindatum passende Abkürzung oder nennen Sie eine eindeutige Stadt, statt ganzjährig CET zu schreiben.
Richten Sie Serientermine nach der maßgeblichen Zeitzone aus. Soll eine Besprechung der Uhr im Berliner Büro folgen, verwenden Sie diese Zeitzone und prüfen Sie die Berechnung der Wiederholungen. Für Teilnehmer im Ausland kann sich die Ortszeit während der Umstellungen ändern. Das ist nicht zwingend eine Terminverlegung; möglicherweise hat sich nur der Zeitunterschied zwischen den Regionen geändert.
Prüfen Sie wichtige Termine rund um die Zeitumstellung erneut. Europa und Nordamerika stellen an unterschiedlichen Tagen um, wodurch sich der übliche Abstand vorübergehend ändert. Prüfen Sie das konkrete Datum und bestätigen Sie die Uhrzeit für beide Seiten schriftlich.
Verwenden Sie ganztägige Ereignisse, wenn nur das Datum zählt. Das eignet sich etwa, um den Tag einer Konferenz zu markieren. Müssen Teilnehmer zu einer bestimmten Uhrzeit erscheinen, erstellen Sie stattdessen einen Termin mit Uhrzeit und Zeitzone. Geben Sie einem Ereignis ohne zeitlichen Bezug keine beliebige Startzeit.
Prüfen Sie ältere Serien und speichern Sie bei Bedarf die geklärte Uhrzeit samt Zeitzone. Eine fehlende Zeitzone in einem alten Eintrag ist nicht automatisch eine korrekt definierte gleitende Zeitangabe. Achten Sie beim Speichern im Webmail auf die Browserkonfiguration. Das gilt auch für den zeitversetzten Versand, dessen eingegebene Uhrzeit von der Gerätezeitzone abhängt.Häufige Fragen
Warum erscheint meine Besprechung in anderen Zeitzonen zu einer anderen Uhrzeit?
Unterschiedliche Ortszeiten bezeichnen normalerweise denselben Zeitpunkt. Ein Fehler liegt vor, wenn Teilnehmer tatsächlich verschiedene Startzeitpunkte erhalten haben. Prüfen Sie dann Ereigniszeitzone und Clienteinstellungen. Fehlte die Zeitzone, klären Sie die ursprüngliche Uhrzeit, speichern Sie die richtige Zeitzone und kontrollieren Sie das Ergebnis mit den Teilnehmern.
Warum hat sich mein Serientermin um eine Stunde verschoben?
Das kann an der Zeitumstellung liegen. Eine Serie mit fester UTC-Uhrzeit behält diese bei, verändert sich aber auf der lokalen Uhr. Eine in einer Ortszeitzone berechnete Serie behält die Ortszeit bei und kann sich für andere Regionen verschieben. Das gewünschte Verhalten hängt von Ihrer Vereinbarung ab; prüfen Sie Berechnung und Export der Serie.
Welche Zeitzone wird beim Erstellen im Webmail verwendet?
Webmail erkennt die Browserzeitzone und überträgt sie für Ereignisse mit Uhrzeit. Der Server speichert UTC-Zeitpunkt und Zeitzone. Prüfen Sie vorher die Geräteeinstellungen, besonders wenn die Besprechung einer anderen Zeitzone als Ihrer aktuellen folgen soll.
Werden ganztägige Ereignisse umgerechnet?
Nein. Sie werden als Datumswerte gespeichert, nicht als Zeitpunkte. Eine Umrechnung über UTC könnte das Datum für Personen in anderen Zeitzonen auf den vorherigen oder folgenden Tag verschieben.
Was passiert mit Ereignissen aus der Zeit vor der Zeitzonenspeicherung?
Sie behalten ihr bisheriges Verhalten, ohne automatische Zeitzonenzuweisung. Webmail ergänzt beim Speichern eines Ereignisses mit Uhrzeit die Browserzeitzone. Prüfen Sie zuerst die Uhrzeit und das Gerät. Bei einem API-Update ohne ausdrücklichen Zeitzonenparameter bleibt ein alter Eintrag ohne Zeitzone.
Funktionieren Zeitzonen mit Apple Calendar und Google Calendar?
Ein kompatibler, richtig eingerichteter CalDAV-Client kann die Ereigniszeit korrekt umrechnen. Für Apple Calendar gibt es eine Einrichtungsanleitung. Prüfen Sie bei Google Calendar den verfügbaren Integrationsweg: Eine Verbindung zu jedem externen CalDAV-Server ist nicht zugesichert. Kontrollieren Sie auch Wiederholungen und Zeitumstellungen.
Kann ich die Zeitzone über die API ausdrücklich setzen?
Ja. Die REST-API zum Erstellen und Aktualisieren von Ereignissen akzeptiert einen Zeitzonenparameter. Prüfen Sie bei MCP das Werkzeugschema und übertragen Sie das Feld, sofern es unterstützt wird. Ohne dieses Feld kann das System die gewünschte Zeitzone nicht zuverlässig herleiten.
Warum kommen Erinnerungen für alte Ereignisse zur falschen Uhrzeit?
Eine ohne Zeitzone gespeicherte Uhrzeit kann beim Vergleich mit dem aktuellen Zeitpunkt zu falschen Ergebnissen führen. Klären Sie die ursprüngliche Zeit, speichern Sie die passende Zeitzone und testen Sie die Erinnerung. Besteht das Problem weiter, prüfen Sie auch die Benachrichtigungseinstellungen und den Aufgabenplaner.
