Terminplanung über Zeitzonen hinweg: ein Praxisleitfaden für Remote-Teams

Verteilte Teams verlieren absurd viel Zeit an dieselbe Handvoll Zeitzonen-Bugs: Meetings, die sich zweimal im Jahr um eine Stunde verschieben, Kalendereinladungen, die zur falschen Zeit ankommen, „9 Uhr für alle“, das es nicht ist. Die Korrekturen sind klein. Der Preis dafür, sie nicht zu machen, ist im Schnitt ein verpasster Produktstart pro Jahr.

IANA-Zonen verwenden, keine festen Offsets

Die IANA Time Zone Database (oft tzdata oder zoneinfo genannt) ist die kanonische Quelle dafür, wie sich Uhren weltweit verhalten. Jede Zone – Europe/Istanbul, America/Los_Angeles, Asia/Tokyo – ist eine Regel: die vollständige Historie der UTC-Offsets, DST-Übergänge und politischen Änderungen für diesen Ort.

Ein bloßer Offset wie GMT+3 oder UTC-5 ist ein Wert. Er ist für manche Orte zu manchen Jahreszeiten korrekt, weiß aber nichts über DST oder künftige gesetzliche Änderungen. Die Türkei schaffte 2016 die Sommerzeit ab und wechselte dauerhaft zu UTC+3; Großbritannien bleibt im Winter bei UTC+0 und im Sommer bei UTC+1. Ein System mit festen Offsets bekommt das still falsch.

Faustregel: Jeder in Ihrer Datenbank gespeicherte Zeitpunkt sollte mit einer IANA-Zonen-ID neben dem UTC-Zeitpunkt reisen. Die Zone sagt Ihnen, wie er anzuzeigen ist; der Zeitpunkt, wann er tatsächlich stattfand. Unser IANA-Zeitzonen-Glossareintrag behandelt das Format genauer.

DST-Umstellungswochen

Der zuverlässigste Weg, Zeitzonen-Bugs in einer Kalender-App zu finden, ist ein Blick auf die zweite März-Woche. Hier ist, warum.

• Vereinigte Staaten wechseln am zweiten Sonntag im März auf Sommerzeit und am ersten Sonntag im November zurück (seit 2007).
• Europäische Union wechselt am letzten Sonntag im März und am letzten Sonntag im Oktober zurück.
• Großbritannien folgt dem EU-Zeitplan (BST beginnt am letzten Sonntag im März).
• Australien (Oststaaten) wechselt in die umgekehrte Richtung im Oktober und April – es liegt auf der Südhalbkugel.
• Japan, China, Indien, der Großteil Afrikas, der Großteil Südamerikas – gar keine Sommerzeit.

Die praktische Folge: Zwischen dem zweiten Sonntag im März und dem letzten Sonntag im März sind die USA auf Sommerzeit, während Europa noch auf Normalzeit ist. Die übliche New-York-/London-Lücke von 5 Stunden schrumpft auf 4. Ein 9-Uhr-Meeting in New York, das normalerweise 14 Uhr London trifft, trifft 13 Uhr London. Wiederkehrende Meetings, die als „9 Uhr America/New_York“ in einem zonen-bewussten Client gespeichert sind, handhaben das korrekt. Wiederkehrende Meetings, die als „14:00 UTC“ gespeichert sind, nicht – sie verschieben sich für europäische Teilnehmer und bleiben für amerikanische gleich.

Die Oktober-Umstellung hat das Spiegelproblem: Europa stellt eine Woche vor den USA zurück und verengt die Lücke kurz erneut.

Praktische Überschneidungsfenster

Für global verteilte Teams ist die Frage nicht „welche Zeit passt“ – es ist „welches Fenster passt ganzjährig, einschließlich der DST-Umstellungswochen“. Hier sind die, die überstehen:

US-Ostküste ↔ Westeuropa

13:00–17:00 UTC. Das ist grob 9–13 Uhr Ostküste und 14–18 Uhr London / 15–19 Uhr Mitteleuropa. Beide Seiten sind klar im Arbeitstag, und die DST-Diskrepanz verschiebt das Meeting in den Umstellungswochen nur eine Stunde früher in der Ortszeit der Europäer. Meiden Sie 17:00–18:00 UTC – die Beteiligung sinkt stark, sobald der europäische Arbeitstag endet.

US-Westküste ↔ Westeuropa

16:00–17:00 UTC. Ein Ein-Stunden-Fenster: 9 Uhr Pazifik = 17 Uhr London. Alles früher verliert die Europäer; alles später verliert die Pazifikküste. Viele Teams akzeptieren das und fahren einen einzigen wöchentlichen Sync, alles andere asynchron.

Westeuropa ↔ Asien (Tokio, Singapur, Seoul)

08:00–10:00 UTC. 9 Uhr London = 18 Uhr Tokio. Früh für London, Tagesende für Tokio. Legen Sie wiederkehrende Meetings auf Montag oder Dienstag, damit keine Seite die Woche eröffnet oder abschließt.

US-Westküste ↔ Asien

14:00–15:00 UTC. Das ist 7 Uhr Pazifik = 23 Uhr Tokio (Winter). Mühsam für beide Seiten. Die meisten Teams, die diese beiden Regionen paaren, verzichten ganz auf Live-Meetings und rotieren die Last, wenn synchrone Zeit unvermeidlich ist.

Für die interaktive Suche zeigt unser Meeting-Planer Überschneidungsbänder über mehrere Zonen. Die Weltuhr ist gut für Auf-einen-Blick-Prüfungen „ist es für die gerade mitten in der Nacht?“.

Fallen bei Kalendereinladungen

ICS ohne TZID

Das iCalendar-(ICS)-Format, das alle großen Kalender-Apps sprechen, kann ein Meeting auf zwei Arten kodieren: als UTC-Zeitpunkt (z. B. DTSTART:20260601T130000Z) oder als an eine Zone gebundene Ortszeit (z. B. DTSTART;TZID=America/New_York:20260601T090000). Die erste Form ist beim Zeitpunkt eindeutig, verschiebt sich aber nicht mit DST. Die zweite Form verschiebt sich, weil der Client des Empfängers die aktuelle Regel für die benannte Zone nachschlägt.

Wiederkehrende Meetings sollten immer die TZID-Form verwenden. Erstellen Sie ein wiederkehrendes Ereignis in einem Tool, das nur UTC speichert, sieht jeder Teilnehmer außerhalb dieser Zone das Meeting zweimal im Jahr um eine Stunde driften.

Outlook- vs. Google-Auslegung

Historisch respektierte Outlook die Zeitzone des Urhebers für die Anzeige, während Google in die Zone des Betrachters konvertierte. Die Verhaltensweisen haben sich angenähert, aber Alt-Meetings (besonders Importe aus älteren Outlook-Archiven) können noch eine Stunde daneben auftauchen. Meldet ein Empfänger die falsche Zeit, ist das Erste zu prüfen, ob die ICS eine TZID-Zeile enthält.

„Schwebende“ Zeiten

Manche Apps unterstützen eine dritte Form: Ortszeit ohne Zone, im Sinne von „9 Uhr, wo immer du bist“. Das ist korrekt für „nimm deine Medikamente um 9 Uhr“- Erinnerungen und fast immer falsch für geteilte Meetings. Meiden Sie es bei der Teamplanung.

Praktische Empfehlungen

• UTC + IANA-Zone speichern. Zwei Spalten: eine für den absoluten Zeitpunkt, eine für die Zone des Urhebers. Anzeige in der Zone des Betrachters.
• Wiederkehrende Meeting-Zeiten nach UTC-Band wählen, nicht nach Ortszeit. Ein „13:00 UTC“-Meeting pro Woche bleibt das ganze Jahr im selben Überschneidungsfenster, auch wenn es sich in der Ortszeit um eine Stunde verschiebt.
• Wiederkehrende Meetings rund um DST-Übergänge prüfen. Blockieren Sie 30 Minuten in der Woche vor jedem Übergang, um zu bestätigen, dass Kalendereinladungen noch dort landen, wo beabsichtigt.
• Standardmäßig asynchron arbeiten. Die günstigste Zeitzonen-Korrektur sind weniger anwesenheitspflichtige Meetings.
• IANA-Zonennamen im Tooling verwenden. „PST“ ist mehrdeutig (Pakistan vs. Pazifik vs. Pitcairn).America/Los_Angeles ist es nicht.

Probieren Sie den Planer aus

Werfen Sie die Zonen Ihres Teams in unseren Meeting-Planer, um grüne/rote Überschneidungsbänder über einen 24-Stunden-Tag zu sehen. Für einmalige Umrechnungen übernimmt der Zeitzonen-Umrechner beliebige Datums- und Zeiteingaben.

Fazit

Zeitzonen-Bugs sind vollständig vermeidbar. Verwenden Sie IANA-Zonennamen, speichern Sie UTC plus Zone, planen Sie wiederkehrende Meetings nach UTC-Band und prüfen Sie rund um DST-Umstellungswochen. Der Großteil kalenderbezogenen Ärgers in verteilten Teams lässt sich auf eine dieser vier verletzten Regeln zurückführen. Sie sind billig zu befolgen; die Alternative sind verpasste Meetings und stiller Groll.