Kostenloser Zeitzonen-Konverter

UTC, GMT und warum Sie IANA-Namen wollen

UTC (koordinierte Weltzeit) ist der globale Zeitstandard, definiert relativ zur Internationalen Atomzeit mit periodischen Schaltsekunden-Anpassungen. GMT (Greenwich Mean Time) ist technisch gesehen eine Zeitzone (UTC+00:00), historisch an das Royal Observatory in Greenwich, London, gebunden. Die beiden werden umgangssprachlich austauschbar verwendet; technisch ist UTC der Standard, mit dem sich alle synchronisieren.

Für die eindeutige Identifikation von Zeitzonen ist der Standard die IANA Time Zone Database (TZDB), ursprünglich 1986 von Arthur David Olson an den US National Institutes of Health erstellt und nun von der IANA gepflegt. Ihr Benennungsformat ist Region/City: America/New_York, Europe/Paris, Asia/Tokyo, Australia/Sydney. Die Stadt ist die größte Stadt der Zone oder ein markanter Ort. Die TZDB wird mehrmals pro Jahr aktualisiert, wenn Länder ihre Sommerzeitregeln ändern, und jedes moderne Betriebssystem, jede Programmiersprache und jeder große Webbrowser liefert eine aktuelle Kopie mit.

Dieser Konverter verwendet die in Ihren Browser eingebaute IANA-Datenbank über die JavaScript-Intl.DateTimeFormat-API, sodass Sommerzeitübergänge, regionale Regeländerungen und historische Sonderfälle korrekt behandelt werden, ohne dass Sie darüber nachdenken müssen.

Zeitzonen-Abkürzungen sind mehrdeutig

Dreibuchstabige Abkürzungen wie „CST“ und „IST“ sehen eindeutig aus, sind es aber nicht:

• CST kann US Central Standard Time (UTC−06:00), China Standard Time (UTC+08:00) oder Cuba Standard Time (UTC−05:00) bedeuten.
• IST kann India Standard Time (UTC+05:30), Israel Standard Time oder Irish Standard Time bedeuten.
• EST bedeutet üblicherweise US Eastern Standard Time (UTC−05:00), aber Australian Eastern Standard Time (UTC+10:00) teilt sich die Abkürzung.

Wenn Sie eine Zeit wirklich präzise kommunizieren müssen, verwenden Sie den IANA-Namen (America/Chicago vs. Asia/Shanghai vs. Asia/Kolkata) oder geben Sie sowohl den Offset als auch die Stadt an. Der Konverter beschriftet jede Spalte mit der IANA-Zone, damit die Besprechungszeit eindeutig ist.

Gängige Zeitzonen auf einen Blick

Halbstunden- und Viertelstunden-Offsets

Nicht jede Zeitzone ist eine ganze Stundenzahl von UTC entfernt. Indien, Sri Lanka (UTC+05:30), der Iran (UTC+03:30 / +04:30), Afghanistan (UTC+04:30) und Myanmar (UTC+06:30) verwenden alle Halbstunden-Offsets. Nepal liegt bei UTC+05:45 und die Chatham-Inseln von Neuseeland bei UTC+12:45 / +13:45. Diese Halb- und Viertelstunden-Offsets sind vor allem für Softwareentwickler von Bedeutung, viele ältere Systeme nahmen ganzstündige Offsets an und gehen bei indischen oder nepalesischen Zeiten stillschweigend kaputt. Die IANA-Datenbank behandelt sie alle korrekt; der Konverter erbt das.

Sommerzeit

Die Sommerzeit (DST) wurde erstmals in William Willetts Flugschrift „The Waste of Daylight“ von 1907 vorgeschlagen und 1916 erstmals förmlich von Deutschland eingeführt, um während des Ersten Weltkriegs Kohle zu sparen. Heute variiert sie stark je nach Rechtsordnung:

• Vereinigte Staaten: Die Sommerzeit läuft vom zweiten Sonntag im März bis zum ersten Sonntag im November (Energy Policy Act von 2005). Hawaii und der Großteil von Arizona beachten sie nicht.
• Europäische Union: Die Sommerzeit läuft vom letzten Sonntag im März bis zum letzten Sonntag im Oktober. Das EU-Parlament stimmte 2019 dafür, die saisonale Zeitumstellung EU-weit abzuschaffen; die Umsetzung wurde auf unbestimmte Zeit verschoben, und die meisten Mitgliedstaaten beachten weiterhin die Sommerzeit.
• Beachtet keine Sommerzeit: der Großteil Afrikas, der Großteil Asiens, der Großteil Südamerikas (Brasilien schaffte sie 2019 ab), Russland (seit 2014), Island, Hawaii, der Großteil von Arizona, Indien, China, Japan, Südkorea, die Türkei.

Der Konverter berücksichtigt die Sommerzeitregeln jeder IANA-Zone, sodass eine für 9 Uhr in America/New_York an einem Januar-Datum angesetzte Besprechung als EST (UTC−05:00) umgerechnet wird; dieselben 9 Uhr im Juli werden als EDT (UTC−04:00) umgerechnet.

Sommerzeit-Fallstricke in Software

• „Vorstellen“: Die lokalen Uhren springen von 02:00 auf 03:00 Uhr, sodass die Stunde von 02:00 bis 02:59 Uhr lokal nicht existiert. Cron-Jobs, die in diesem Fenster geplant sind, laufen bei Linux Vixie cron unmittelbar nach dem Sprung, werden von AWS EventBridge aber vollständig übersprungen.
• „Zurückstellen“: 02:00 auf 01:00 Uhr passiert zweimal. Ereignisse in der doppelten Stunde können je nach Scheduler zweimal oder gar nicht ausgelöst werden. Linux Vixie führt nicht erneut aus; AWS EventBridge läuft nur einmal.
• Kalendereinladungen, die eine Sommerzeitgrenze überspannen, brauchen die ausdrücklich angehängte Zeitzone, nicht nur die Ortszeit. ICS-Dateien enthalten aus diesem Grund eine TZID; ein schlichtes „9 AM ET“ per E-Mail zu senden, wenn der Kalender des Empfängers eine Sommerzeitumstellung überspannt, verschiebt sich stillschweigend um eine Stunde.

Häufige Anwendungsfälle

• Besprechungen über Kontinente hinweg planen: Was wird aus 9 Uhr PST für jemanden in Tokio oder Berlin? Wann sind alle gleichzeitig zu Bürozeiten erreichbar?
• Produkteinführungen koordinieren, die „überall um Mitternacht live gehen“ oder „um 9 Uhr Ihrer Ortszeit“ stattfinden sollen.
• Server-Logs lesen in Ihrer Ortszeit, wenn der Server auf UTC eingestellt ist (die moderne beste Praxis für Cloud-Server).
• Reiseplanung: Um welche Ortszeit lande ich? Wann startet mein Flug in der Zeit des Zielorts?
• Mit internationalen Kunden koordinieren, ohne durch Kopfrechnen Fehler bei der Zeitzonen-Mathematik zu machen.
• Planung von Live-Events: Game-Streams, Webinare, Sportübertragungen, die für ein globales Publikum eine einzige Antwort auf „Läuft das gerade?“ brauchen.

Häufige Fehler

1. „EST“ mit „EDT“ verwechseln (oder ein beliebiges Paar aus Normal- und Sommerzeit). Dieselbe Besprechung am 1. März gegenüber dem 31. März in New York liegt bei einem anderen UTC-Offset.
2. „GMT“ verwenden, um „britische Zeit“ zu meinen. Das Vereinigte Königreich beachtet von Ende März bis Ende Oktober die British Summer Time (BST, UTC+01:00); nur der Winter ist GMT.
3. Annehmen, dass eine Stadt einen festen UTC-Offset hat. Russland, Samoa, Ägypten und andere haben ihre Offsets alle in den letzten 15 Jahren geändert. Die IANA-Datenbank verfolgt die Historie; Abfragen nach Stadtname und Datum bleiben korrekt.
4. Einladungen mit dreibuchstabigen Abkürzungen versenden. „9 AM CST“ ist tatsächlich mehrdeutig zwischen Chicago (UTC−06:00) und Shanghai (UTC+08:00), ein Unterschied von 14 Stunden. Verwenden Sie IANA-Namen oder geben Sie den Offset an.
5. Arizona, Hawaii, Saskatchewan, Indiana vergessen. Diese Orte beachten die Sommerzeit entweder nicht oder nur teilweise. Generische Zuordnungen wie „Mountain Time“ oder „Central Time“ brechen die Hälfte des Jahres.
6. Eine Besprechung in einer Stunde wählen, die nicht existiert. Eine Einladung für 02:30 Uhr Ortszeit am Tag der Vorstellung liegt in einer nicht existierenden Stunde. Der Kalender verschiebt sie meist stillschweigend; manche Systeme erzeugen einen Fehler.

Weitere häufig gestellte Fragen

Warum sind manche Offsets in halben Stunden?

Historische und politische Gründe. Indien einigte sich auf UTC+05:30, teils als Kompromiss zwischen der Ost- und Westausdehnung des Landes; der Iran, Afghanistan, Myanmar und eine Handvoll anderer verwenden ähnliche Halbstunden-Offsets. Nepal geht noch einen Schritt weiter und verwendet UTC+05:45. Es gibt keine Regel, dass Zeitzonen auf ganzstündigen Grenzen liegen müssen, sie sind, was jede Rechtsordnung gewählt hat.

Wie behandelt der Konverter Sommerzeitübergänge?

Automatisch. Die IANA-Datenbank des Browsers enthält die Sommerzeitregeln jeder Region, einschließlich der historischen. Eine in Europe/Berlin an einem Sommerdatum gesetzte Zeit wird korrekt mit CEST (UTC+02:00) umgerechnet; dieselbe Ortszeit im Winter wird mit CET (UTC+01:00) umgerechnet.

Welche Zeitzonen kann ich hinzufügen?

Alle IANA-Zeitzonen, die der Browser kennt, typischerweise mehr als 400 Zonen, die jede besiedelte Region abdecken. Das Dropdown wird beim Laden der Seite aus Intl.supportedValuesOf('timeZone') des Browsers befüllt, sodass es stets aktuell bleibt, je nachdem, was Ihr Betriebssystem installiert hat.

Wird meine umgerechnete Zeit irgendwohin gesendet?

Nein. Die Umrechnung erfolgt vollständig in Ihrem Browser mit den eingebauten JavaScript-APIs für Datum und Zeitzonen. Nichts über Ihre Besprechungszeiten, Orte oder ausgewählten Zonen wird übertragen, protokolliert oder auf einem Server gespeichert.

Warum verschiebt sich die Besprechungszeit rund um die Sommerzeit?

Weil manche Zonen die Sommerzeit beachten und andere nicht. Eine Besprechung um 9 Uhr Pazifik trifft im Winter auf 12 Uhr Ostküste (beide in Normalzeit), aber dieselben 9 Uhr Pazifik bleiben im Sommer bei 12 Uhr Ostküste (beide in Sommerzeit). Eine Besprechung um 9 Uhr Pazifik trifft jedoch das ganze Jahr über auf 1 Uhr am nächsten Tag in Tokio, Tokio beachtet keine Sommerzeit, sodass sich der Unterschied zwischen LA und Tokio zweimal im Jahr um eine Stunde verschiebt.

Was ist der sicherste Weg, eine Besprechungszeit zu teilen?

Senden Sie eine Kalendereinladung (.ics-Datei oder über Google / Outlook / iCloud Calendar) mit ausdrücklich angehängter Zeitzone. Der Kalender des Empfängers stellt die Zeit dann in seiner lokalen Zone dar und berücksichtigt die Sommerzeit an beiden Enden automatisch. Wenn Sie eine Zeit als Klartext senden müssen, geben Sie sowohl die IANA-Zone als auch den Offset an: „Dienstag 14:00 Europe/Berlin (UTC+01:00).“