Konvertieren Sie ein Datum und eine Uhrzeit zwischen beliebigen zwei IANA-Zeitzonen mit Berücksichtigung der Sommerzeit.
Verwendet die IANA tzdata Ihres Browsers — Sommerzeitumstellungen werden korrekt behandelt. Für Flug- oder medizinische Zwecke immer mit der offiziellen Quelle abgleichen.
Die Planung einer Besprechung über Zeitzonen hinweg ist die tägliche Reibung der Fernarbeit. "Dienstag um 16 Uhr Paris" ist für einen Pariser eindeutig und für alle anderen mehrdeutig: Ist das Pazifische Sommerzeit um 7 Uhr oder Pazifische Standardzeit um 7 Uhr, je nachdem, ob Frühling oder Herbst? Die Sommerzeit ist in den Hemisphären unterschiedlich (Sydney stellt die Uhren zurück, wenn Paris vorstellt) und über Jahrzehnte hinweg (im Jahr 2024 hat ein Großteil Südamerikas die Sommerzeit komplett aufgegeben). Das IANA tzdata-Projekt pflegt die kanonische Zuordnung jeder benannten Zeitzone zu ihrer Offset-Historie, und jeder moderne Browser liefert eine lokale Kopie, die die Regeln automatisch verarbeitet. Dieser Rechner ist die Benutzeroberfläche für diese Daten: Geben Sie ein Datum, eine lokale Uhrzeit und eine Quellzeitzone ein; wählen Sie eine Zielzeitzone aus; erhalten Sie die entsprechende lokale Uhrzeit am Zielort sowie den Offset zwischen den beiden Zonen für diesen spezifischen Zeitpunkt. Die 20 Städte in der Dropdown-Liste decken die Mehrheit der Besprechungen über Zeitzonen hinweg ab: die wichtigsten europäischen Hauptstädte, die kontinentalen US-Zonen, die vier primären asiatischen Geschäftszentren, die Städte der südlichen Hemisphäre und UTC als eindeutige Referenz.
Es gibt keine geschlossene Formel – der Rechner delegiert an die Intl.DateTimeFormat-API des Browsers, die über das Betriebssystem Zugriff auf die IANA tzdata hat. Intern: (1) Erstellen Sie einen UTC-Zeitpunkt, der, wenn er in der Quellzeitzone interpretiert wird, die angezeigte lokale Uhrzeit des Benutzers wiedergibt. Dies erfordert eine kleine Zweidurchlauf-Schleife: Nehmen Sie die Eingaben so, als wären sie UTC, fragen Sie Intl, was die Quellzone zu diesem Zeitpunkt anzeigt, berechnen Sie den Offset zwischen der angezeigten und der beabsichtigten lokalen Uhrzeit, subtrahieren Sie diesen Offset, um den tatsächlichen UTC-Zeitpunkt zu finden. (2) Formatieren Sie denselben UTC-Zeitpunkt in der Zielzone unter Verwendung von Intl.DateTimeFormat mit timeZone: <Ziel>. (3) Berechnen Sie die Offset-Differenz zwischen den beiden Zonen für diesen spezifischen Zeitpunkt – erforderlich, da der Offset nicht fest ist; er variiert mit der Sommerzeit. Das Ergebnis enthält Wochentag, vollständiges Datum, Stunde und Minute sowie die Zonenabkürzung (CET, EST, JST usw.) zur Verdeutlichung.
Vier Eingaben: Datum (Datumsauswahl), Uhrzeit (24-Stunden-Uhrzeitauswahl), Quellzeitzone (Dropdown), Zielzeitzone (Dropdown). Standardwerte: heute um 14:30 Uhr, Paris nach New York. Das Ergebnis-Panel zeigt die Quellzeit und die Zielzeit als zwei große, parallele KPIs an, und darunter die UTC-Referenzzeit und den Offset zwischen den beiden Zonen für diesen Zeitpunkt. Die 20-Städte-Dropdown-Liste umfasst Europa (Paris, London, Berlin, Moskau), Amerika (New York, Chicago, Denver, Los Angeles, São Paulo), Afrika (Kairo, Johannesburg), Asien (Dubai, Mumbai, Peking, Tokio, Singapur, Seoul), Ozeanien (Sydney, Auckland) sowie UTC. Fügen Sie neue Städte hinzu, indem Sie die Dropdown-Liste bearbeiten; die zugrunde liegende Maschinerie verarbeitet jeden IANA-Zonenbezeichner.
Ein Pariser Team möchte am 15. Mai 2026 um 14:30 Uhr Pariser Zeit ein Kick-off-Meeting mit seinem New Yorker Gegenüber planen. Quelle: 14:30 Uhr am 15. Mai 2026 in Europe/Paris (CEST, UTC+2 im Mai, da die Sommerzeit in Kraft ist). Ziel: America/New_York (EDT, UTC-4 im Mai). Quelle zu UTC: 14:30 - 02:00 = 12:30 UTC. UTC zu Ziel: 12:30 + (-04:00) = 08:30 EDT. Also 14:30 Paris = 08:30 New York am selben Tag, ein Offset von 6 Stunden. Betrachten wir nun den 15. Januar 2026 um 14:30 Uhr Paris (CET, UTC+1) → New York (EST, UTC-5). Quelle zu UTC: 14:30 - 01:00 = 13:30 UTC. UTC zu Ziel: 13:30 - 05:00 = 08:30 EST. Gleiche Wanduhr-Konvertierung, aber nur, weil sowohl Paris als auch New York Standardzeit haben; wenn Paris auf Sommerzeit umgestellt hätte und New York nicht (eine reale Situation Ende März jedes Jahres), wäre der Offset 5 Stunden statt 6. Der Rechner handhabt dies transparent: Der Benutzer muss die Sommerzeit über zwei Zonen hinweg nicht verfolgen; die IANA-Datenbank erledigt das für ihn. Ein dramatischeres Beispiel: 15. Dezember 2026 um 09:00 Uhr Sydney (AEDT, UTC+11) → London (GMT, UTC+0). Quelle zu UTC: 09:00 - 11:00 = -02:00 UTC, was 22:00 Uhr am Vortag ist. London um 22:00 Uhr am 14. Dezember – über die Datumsgrenze hinweg in Kalenderbegriffen, 11 Stunden Unterschied in Uhrzeitbegriffen.
Erstens, Verwechslung von UTC-Offset und Zeitzone. "UTC+1" beschreibt den Offset; "Europe/Paris" beschreibt die Zeitzone. Paris ist im Winter UTC+1 und im Sommer UTC+2. Festeingestellte Werte von UTC+1 für "französische Zeit" ergeben einen Fehler von einer Stunde von Ende März bis Ende Oktober. Zweitens, Ignorieren der Sommerzeit. Paris und New York führen beide die Sommerzeit ein, aber zu unterschiedlichen Zeiten: Mitte März ist Paris noch zwei Wochen lang CET (UTC+1), während New York bereits auf EDT (UTC-4) umgestellt hat; der Offset beträgt in diesem Zeitraum 5 Stunden statt 6. Der Rechner handhabt dies; manuelle Konvertierungen liegen meist falsch. Drittens, Vermischen von 12-Stunden- und 24-Stunden-Schreibweise über Kulturen hinweg. Die USA und Großbritannien verwenden umgangssprachlich 12-Stunden-Uhren mit AM/PM; Kontinentaleuropa verwendet 24-Stunden. Die Auswahl im Rechner ist 24-Stunden; die Zielausgabe verwendet ebenfalls 24-Stunden zur Eindeutigkeit. Viertens, Planung über eine Datumsgrenzenüberschreitung, ohne es zu bemerken. Tokio um 09:00 Uhr Dienstag ist San Francisco um 17:00 Uhr Montag – ein Offset von 16 Stunden, der den Kalendertag überschreitet. Der Rechner zeigt das vollständige Datum im Ziel an, nicht nur die Uhrzeit, um dies sichtbar zu machen. Fünftens, Behandlung des Konverters als maßgeblich für rechtliche oder luftfahrtbezogene Zwecke. Der Rechner verwendet die tzdata des Browsers, die bei Aktualisierung des Betriebssystems aktualisiert wird; wenn der Benutzer ein altes System verwendet, sind die Regeln für neuere Sommerzeitänderungen (z. B. die Abschaffung der Sommerzeit in Brasilien 2019, die teilweise Abschaffung der Sommerzeit in Mexiko 2022) möglicherweise veraltet. Für bindende Kontexte immer die offizielle Quelle prüfen.
Zeitzonen sind ein politisch fließendes System. Sommerzeitänderungen sind üblich: Die EU diskutiert die Beendigung der Sommerzeit seit 2018 (bis 2025 keine Einigung erzielt); Russland hat die Sommerzeit 2014 abgeschafft; Mexiko hat sie 2022 in den meisten Regionen abgeschafft; Iran hat sie 2022 abgeschafft. Das IANA tzdata-Projekt erfasst all diese Änderungen und liefert mehrmals im Jahr Updates; moderne Betriebssysteme ziehen diese automatisch. Halbstunden- und Viertelstunden-Offsets existieren: Indien ist UTC+5:30, Iran UTC+3:30, Neufundland UTC-3:30, Nepal UTC+5:45, Chatham-Inseln UTC+12:45. Der Rechner handhabt diese transparent, da IANA dies tut. Polarregionen verwenden diejenige Zeitzone, die administrativ praktisch ist; Antarktisstationen können der Zeit ihrer versorgenden Nation folgen. Historische Konvertierungen (eine Besprechungszeit von 1956 in Berlin nach NYC) werden ebenfalls von IANA unterstützt, die die gesamte Offset-Historie für jede Zone aufzeichnet. Programmatische Konvertierungen im Code sollten Zeitstempel immer in UTC speichern und erst bei der Anzeige in die lokale Zeit umwandeln; dieser Rechner demonstriert die Konvertierung an der Grenze, wo der Benutzer das Ergebnis sieht.