UTC

UTC (Koordinierte Weltzeit) ist der globale Referenzzeitstandard. Jede andere gebräuchliche Zeitzone ist als Offset zu UTC definiert — meist eine ganze Anzahl Stunden, gelegentlich eine halbe oder Viertelstunde (Indien ist UTC+5:30; Nepal ist UTC+5:45). UTC selbst kennt keine Sommerzeit.

UTC wird vom Internationalen Büro für Maß und Gewicht (BIPM) und dem Internationalen Erdrotations- und Referenzsystemdienst (IERS) geführt. Sein Takt ergibt sich aus einem gewichteten Mittel von Atomuhren in über 80 Laboren weltweit. Gelegentliche Schaltsekunden wurden eingefügt (oder hypothetisch entfernt), um UTC innerhalb von 0,9 Sekunden zur Sonnenzeit zu halten. Stand 2026 ist die Abschaffung der Schaltsekunde für 2035 geplant.

UTC wird oft mit GMT (Greenwich Mean Time) verwechselt. Für die meisten praktischen Zwecke sind sie identisch — beide stehen für die Zeit am Greenwich-Meridian ohne Sommerzeit. Der technische Unterschied: GMT ist durch die Erdrotation definiert (die unregelmäßig ist), UTC durch Atomuhren (die gleichmäßig sind). Wenn im Vereinigten Königreich Sommerzeit gilt, herrscht dort BST (British Summer Time = UTC+1); GMT bleibt dann als Uhrenbezeichnung ungenutzt, auch wenn der Zeitzonenname fortbesteht.

Rechnen Sie mit unserem Zeitzonen-Umrechnerzwischen UTC und 28 großen Zeitzonen um — er nutzt die IANA-Zeitzonendatenbank des Browsers für sommerzeitkorrekte Ergebnisse.

Warum „UTC“ statt CUT oder TUC: das Kürzel ist ein bewusster Kompromiss. Englischsprachige wollten „CUT“ (Coordinated Universal Time); Französischsprachige wollten „TUC“ (Temps Universel Coordonné). ITU und BIPM einigten sich 1970 auf UTC als sprachneutrale Reihenfolge, die zu keiner der beiden Ausschreibungen exakt passt. Konvention ist, das Kürzel unabhängig von der umgebenden Ausschreibung in Großbuchstaben zu schreiben.

UTC im Code — was man tatsächlich speichert: die operative Regel für jedes System mit Mehrzeitzonen-Daten lautet „in UTC speichern, in Ortszeit darstellen“. Datenbank-Zeitstempel gehören in UTC (PostgreSQL TIMESTAMP WITH TIME ZONE normalisiert intern auf UTC; MySQL TIMESTAMP tut dasselbe; MongoDB Date ist laut Spezifikation UTC). Die Anzeigeschicht rechnet zur Renderzeit in die Locale des Nutzers um. Das Speichern lokaler Wanduhrzeiten ohne Zoneninformation ist die klassische Quelle des Fehlers „die Buchung verschob sich nach der Sommerzeitumstellung um eine Stunde“ und gilt durchweg als Anti-Pattern. Quelle: BIPM — Coordinated Universal Time (UTC).

Durchgerechnetes Beispiel

Eine Nutzerin in New York plant ein Meeting für „15:00 Uhr am 5. November 2025“. Das Backend sollte dies als UTC-Zeitpunkt speichern. New York ist am 5. November EST (UTC−5) (die Sommerzeit endete am 2. November), der gespeicherte Wert ist also 2025-11-05T20:00:00Z. Ein zweiter Eingeladener in Berlin sieht dasselbe Meeting: Berlin ist zu diesem Datum CET (UTC+1), der Kalender zeigt also 2025-11-05 21:00 CET. Ein dritter Eingeladener in Tokio (UTC+9, keine Sommerzeit) sieht 2025-11-06 05:00 JST — derselbe Zeitpunkt, unterschiedliche Wanduhren, alle aus einem gespeicherten UTC-Zeitstempel abgeleitet. Angenommen, das Meeting wiederholt sich wöchentlich: „jeden Mittwoch um 20:00 UTC“ zu speichern, würde für die New Yorkerin nach dem Sommerzeitende stillschweigend driften (sie erwartete 15 Uhr Ortszeit, bekäme nach dem Übergang am 2. November aber 16 Uhr Ortszeit). Kalendersysteme lösen das, indem sie wiederkehrende Termine in der Ursprungszone mit angehängtem IANA-Zonennamen speichern und erst beim Rendern auf UTC expandieren.

Wann und warum es zählt

Fast jeder Fehler vom Typ „das Meeting verschob sich“, „der Bericht lief zur falschen Stunde“ oder „der Cronjob feuerte über die Sommerzeit hinweg doppelt“ lässt sich darauf zurückführen, dass Ortszeit ohne Zone gespeichert wurde oder der Zonen-Offset (+01:00) statt der Zonenkennung (Europe/Berlin) abgelegt wurde. Der Offset ist für einen einzelnen Zeitpunkt in Ordnung, wird aber für jedes künftige Datum mehrdeutig — die Zonenkennung bewahrt die Sommerzeitregeln. Die pragmatischen Regeln: Zeitpunkte in UTC speichern (oder mit expliziter Zone), nutzerseitige Daten mit IANA-Zonenkennungen ablegen (Europe/Berlin, nicht +01:00), nie dreibuchstabige Zonenkürzel verwenden (CST ist zwischen China, Kuba und dem zentralen US-Raum mehrdeutig) und die Umrechnung einer Zonendatenbank überlassen (tzdata über IANA, vierteljährlich aktualisiert). Quelle: IANA Time Zone Database.