Zeitzonen-Rechner

Ziel-Uhrzeit = Ausgangs-Uhrzeit − Ausgangsversatz + Zielversatz; Versatzdifferenz = Zielversatz − Ausgangsversatz; Tagesverschiebung = Zieldatum − Ausgangsdatum

date

Der Kalendertag am Ausgangsort, geschrieben als JJJJ-MM-TT. Es ist der Tag dort drüben und nicht der Tag, an dem Sie das hier lesen

time

Die Uhrzeit am Ausgangsort, als HH:MM oder HH:MM:SS in 24-Stunden-Form. Sekunden dürfen weggelassen werden; im Ergebnis stehen sie immer

fromZone

Die Zone, zu der die eingetippte Zeit gehört. Eine von 22 IANA-Zonen, jede mit ihrer Stadt benannt statt mit ihrem Versatz, weil der Versatz eine Eigenschaft des Augenblicks ist und nicht des Ortes

toZone

Die Zone, in die umgerechnet wird. Dieselben 22 Zonen wie in der Ausgangsliste

toTime

Die Uhrzeit in der Zielzone, immer mit Sekunden. Das ist das Hauptergebnis

toDate

Das Kalenderdatum in der Zielzone, das nicht immer das eingegebene ist — genau darum geht es bei der Tagesverschiebung

toWeekday

Der Wochentag in der Zielzone, in Ihrer Sprache ausgeschrieben

fromOffset

Wie weit die Ausgangszeitzone zum aufgelösten Zeitpunkt von UTC entfernt ist, als UTC-Versatz in der Form UTC±HH:MM

toOffset

Wie weit die Zielzeitzone zum selben Zeitpunkt von UTC entfernt ist. Beide Versätze werden zum umgerechneten Zeitpunkt abgelesen und enthalten deshalb beide die Sommerzeit, wo sie gerade gilt

offsetDifference

Zielversatz minus Ausgangsversatz, in Stunden. Ein negativer Wert heißt, dass der Zielort hinter dem Ausgangsort liegt

dayShift

Tagesverschiebung: −1, 0 oder +1 — ob das Zieldatum der Tag davor, derselbe Tag oder der Tag danach ist

Nutzen Sie den Rechner, sobald zwei Orte im Spiel sind und eine Uhr stimmen muss: einen Anruf über einen Ozean hinweg ansetzen, prüfen, ob ein Flug an dem Tag landet, an dem er abgehoben ist, ein Serverprotokoll in UTC lesen oder klären, warum der »Sonntagvormittag« eines Bekannten Ihr Sonntagabend ist. Die Tagesverschiebung ist der Teil, der von Hand schiefgeht, weil sie keine feste Eigenschaft des Städtepaares ist — dieselben zwei Zonen unterscheiden sich im Januar um 12 Stunden und im Juli um 11. Diese Seite rechnet einen Zeitpunkt um, den Sie bereits haben; sie sagt Ihnen nicht, in welcher Zone ein Ort liegt (die Listen stehen fest bei 22 Zonen), und sie weiß nichts über Reisedauern, Flugzeiten oder Terminerinnerungen.

1. Mittag in Shanghai — in New York ist es noch der Vortag

   1. Shanghai liegt im Januar auf UTC+08:00, Mittag dort ist also 04:00 UTC am 15. Januar
   2. New York läuft auf EST, UTC-05:00, 04:00 UTC liest sich dort also als 23:00 auf der Uhr
   3. 23:00 liegt vor Mitternacht, das Datum rutscht damit auf den 14. Januar — einen Tag vor den eingegebenen —, und die Tagesverschiebung sagt das mit −1
   4. Der Wochentag am Zielort steht in seiner eigenen Zeile und richtet sich nach dem Zieldatum
   5. Zwischen UTC+08:00 und UTC-05:00 liegen 13 Stunden, und der Zielort ist der weiter westlich gelegene; die Versatzdifferenz ist deshalb −13

   Der Ausgangszustand des Rechners und der Fall, der am meisten überrascht: Eine Nachricht, die in Shanghai mittags abgeschickt wird, erreicht New York am Kalendertag davor. Genau hier schleicht sich der Fehler ein, wenn man von Hand mit einer Regel wie »Shanghai liegt zwölf oder dreizehn Stunden voraus« arbeitet — hier sind es 13, im Juli aber 12, weil New York dann Sommerzeit hat und Shanghai nicht.

2. Eine Uhrzeit, die es nicht gibt: New York, 8. März 2026, 02:30

   1. In New York werden die Uhren an diesem Datum um 02:00 Ortszeit vorgestellt, aus 02:00 wird also 03:00, und die halbe Stunde von 02:00 bis 03:00 findet nie statt
   2. Die eingetippten 02:30 existieren damit nicht. Die Seite liest sie so, wie es die IANA-Regeln für eine solche Lücke vorschreiben: Sie schiebt sie nach vorn und kommt auf 03:30 in der EDT
   3. Weil der aufgelöste Zeitpunkt bereits in der EDT liegt, meldet der Ausgangsversatz UTC-04:00 — nicht das UTC-05:00, das 02:30 einen Tag vorher getragen hätte
   4. Shanghai liegt auf UTC+08:00 und damit zwölf Stunden vor der EDT, aus 03:30 wird also 15:30 am selben Tag
   5. Die Tagesverschiebung ist 0, der Zielort bleibt also beim eingegebenen Datum, und der Wochentag steht in seiner eigenen Zeile

   Der Versatz neben einer eingetippten Uhrzeit kann falsch aussehen, bis man den Grund sieht: 02:30 in New York ist im Winter eine Uhrzeit der Zone UTC-05:00, doch genau diese 02:30 fällt in die Lücke nach der Umstellung, der aufgelöste Zeitpunkt gehört also bereits zur EDT und meldet UTC-04:00. Die Seite liest Lücken und Doppelungen so, wie es die IANA-Zeitzonendatenbank vorschreibt, und weist keine Eingabe ab — das Ergebnis kommt deshalb immer, und dieser Fall ist der, den man zweimal lesen sollte.

3. Beide Seiten auf Sommerzeit: London nach Los Angeles am 4. Juli

   1. Im Juli läuft London auf BST, UTC+01:00, 09:30 dort sind also 08:30 UTC
   2. Los Angeles läuft auf PDT, UTC-07:00, 08:30 UTC liest sich dort also als 01:30 auf der Uhr
   3. Die Versätze unterscheiden sich um 8 Stunden. Im Januar sind es ebenfalls 8 — aber andere Achten: dann steht London auf UTC+00:00 und Los Angeles auf UTC-08:00
   4. Beide ausgegebenen Versätze enthalten ihre Sommerzeit, deshalb liest sich der Ausgangsort als UTC+01:00 und nicht als UTC+00:00
   5. Das Datum bleibt unverändert, die Tagesverschiebung ist also 0, und der Wochentag am Zielort steht in seiner eigenen Zeile

   Mit den Standardversätzen (UTC+00:00 und UTC-08:00) kommt dieselbe Stundendifferenz und dieselbe Uhrzeit heraus — genau deshalb fällt der Fehler hier nicht auf, sondern erst an den Tagen beiderseits einer Umstellung. Wenn beide Zonen in derselben Märzwoche in entgegengesetzte Richtungen schalten, liegt eine Regel mit festen Versätzen um eine volle Stunde daneben.

4. Neujahr in Auckland, in UTC noch das alte Jahr

   1. Auckland läuft im Januar auf NZDT, UTC+13:00, Mitternacht dort ist also 11:00 UTC am 31. Dezember 2025
   2. Die Umrechnung nach UTC überschreitet damit gleichzeitig eine Tages- und eine Jahresgrenze
   3. Das Zieldatum ist der 31. Dezember 2025, und die Tagesverschiebung von −1 entsteht durch Subtraktion der Tagesnummern und nicht durch einen Vergleich von Datumszeichenketten
   4. Der Wochentag in der Ergebniszeile gehört zum Zieldatum, nicht zum eingegebenen Datum — deshalb kann er ein anderer sein als der des Tages, den Sie eingetippt haben
   5. Die Versatzdifferenz beträgt −13 Stunden: Der Zielort UTC ist der weiter westlich gelegene

   Die Tagesverschiebung ist nicht einfach »westwärts ist gestern«. Hier überschreiten −13 Stunden die Mitternacht; dieselben −13 Stunden zwischen Shanghai und New York landen ebenfalls am Vortag, während −5 Stunden von London nach New York das nicht tun. Der Wochentag wird für das Zieldatum gemeldet, deshalb kann er von dem des eingegebenen Datums abweichen.

Der Rechner deckt 1970 bis 2100 ab und 22 Zeitzonen, nicht jede Zone, die die IANA-Datenbank kennt. Das Fenster ist Absicht: Vor 1970 hält die Datenbank fest, welche örtliche mittlere Sonnenzeit ein Ort tatsächlich geführt hat — Shanghai stand auf UTC+08:06, Monrovia benutzte einen Versatz mit Sekunden darin —, und solche Antworten sind zwar richtig, lesen sich aber wie ein Fehler. Mehrdeutige und nicht existierende Uhrzeiten werden so aufgelöst, wie es die IANA-Regeln vorschreiben (über eine Lücke in der Sommerzeit nach vorn schieben, bei einer Doppelung im Herbst die frühere der beiden Lesarten nehmen), statt abgewiesen zu werden; die Seite warnt nicht, dass es geschehen ist, die Tage rings um eine Umstellung sind deshalb einen Blick auf die angezeigten Versätze wert. Aus einem eingetippten Ortsnamen wird keine Zone abgeleitet, weil es nichts einzutippen gibt: Beide Listen stehen fest. Die Seite weiß nicht, in welcher Zone Ihr eigenes Gerät läuft, rechnet keine Dauern und keine Flugzeiten aus und berücksichtigt keine Schaltsekunden — jede Minute zählt hier sechzig Sekunden, weshalb eine Angabe in der Nähe einer eingeschobenen Schaltsekunde um eine Sekunde danebenliegen kann; Schaltsekunden werden international festgelegt und sind ein eigenes Thema, und die Zeitskalen selbst werden in Deutschland von der Physikalisch-Technischen Bundesanstalt realisiert.

Wie groß ist der Zeitunterschied zwischen zwei Städten?

Der Zeitunterschied zwischen Städten ist keine feste Zahl, und die Versatzdifferenz, die diese Seite ausgibt, ist die, die an dem eingegebenen Datum gilt. Zwei Zonen können sich im Januar um 13 Stunden und im Juli um 12 unterscheiden, weil die eine die Sommerzeit kennt und die andere nicht. Die Frage nach dem Unterschied zwischen zwei Orten lässt sich also nur mit einem Datum beantworten, und deshalb gehört das Datumsfeld hier zur Frage und ist keine Zugabe.

Wie setze ich einen Besprechungstermin über Zeitzonen hinweg an?

Legen Sie den Termin in der Zone an, in der er vorgeschlagen wurde, und rechnen Sie ihn dann nacheinander in jede weitere Zone um. Bei einem Besprechungstermin über Zeitzonen hinweg ist die Tagesverschiebung meist die nützlichere Zahl als die Stunde: Ein Anruf um 09:00 in London ist am selben Tag 18:00 in Tokio, aber 04:00 in New York, und die 04:00 entscheidet darüber, ob die Einladung zumutbar ist. Weil die Seite auch Wochentag und Datum meldet, sehen Sie außerdem, wann ein Vorschlag auf dem Wochenende der anderen Seite gelandet ist.

Wird die Sommerzeit automatisch berücksichtigt?

Ja, für beide Zonen und für das genaue Datum statt für heute. Die Sommerzeit ist keine Eigenschaft einer Zone, sondern eines Augenblicks: Die ausgegebenen Versätze sind die, die die IANA-Regeln für den umgerechneten Zeitpunkt nennen, ein Januardatum und ein Julidatum zwischen denselben zwei Zonen können deshalb eine Stunde auseinanderliegen. Über das heutige Datum wird nichts angenommen, ein Ergebnis für den nächsten März enthält also bereits die Umstellung im nächsten März.

Warum ist der UTC-Versatz manchmal nicht der erwartete?

Weil der angezeigte Versatz zu dem Zeitpunkt gehört, zu dem die Eingabe aufgelöst wurde, und nicht zu der Uhrzeit, die Sie eingetippt haben. An dem Tag, an dem die Uhren vorgestellt werden, existiert die übersprungene Stunde nicht, und eine Zeit aus dieser Stunde wird als der Augenblick direkt danach gelesen — eine 02:30, die für New York an einem Umstellungstag im März eingegeben wird, meldet deshalb UTC-04:00 (EDT) und nicht das UTC-05:00, das 02:30 einen Tag vorher getragen hat. Beide Angaben beschreiben denselben Zeitpunkt; nur eine davon ist der damals geltende Versatz.

Welcher Tag ist dort, wenn hier Mittwoch ist?

Das hängt von der Stunde ab und nicht nur von den Zonen, und deshalb fragt diese Seite nach beidem. Über die Datumsgrenze nach Osten gewinnen Sie einen Tag; rechnen Sie weit genug nach Westen, verlieren Sie einen. Die Tagesverschiebung beantwortet das unmittelbar mit −1, 0 oder +1, und der Wochentag in der Ergebniszeile benennt den Tag am Zielort, sodass sich erkennen lässt, ob die andere Seite den Tag, nach dem Sie fragen, bereits erreicht hat.

• IANA Time Zone Database — Internet Assigned Numbers Authority
• Theory and pragmatics of the tz code and data — IANA — the source for the 1970-01-01 accuracy window this page states
• Temporal documentation — Time zone handling — TC39 — describes the 'compatible' disambiguation rule this page follows
• PTB — Zeit und Frequenz — Physikalisch-Technische Bundesanstalt