Zum Hauptinhalt springen

4. Lokale Zeit

4.1. Koordinierte Weltzeit (UTC)​

Da die Sommerzeitregeln für lokale Zeitzonen so kompliziert sind und sich zu unvorhersehbaren Zeiten aufgrund lokaler Gesetze ändern können, wird echte Interoperabilität am besten durch die Verwendung der Koordinierten Weltzeit (UTC) erreicht. Diese Spezifikation berücksichtigt keine lokalen Zeitzonenregeln.

Warum UTC verwenden?

  • ✅ Global einheitlicher Zeitstandard
  • ✅ Nicht von Sommerzeit betroffen
  • ✅ Nicht von politischen Entscheidungen betroffen
  • ✅ Gewährleistet Interoperabilität

4.2. Lokale Offsets​

Der Offset zwischen lokaler Zeit und UTC ist oft nützliche Information. Zum Beispiel bietet in elektronischer Post (RFC2822, [IMAIL-UPDATE]) der lokale Offset eine nützliche Heuristik zur Bestimmung der Wahrscheinlichkeit einer prompten Antwort. Versuche, lokale Offsets mit alphabetischen Zeichenketten zu kennzeichnen, haben in der Vergangenheit zu schlechter Interoperabilität geführt [IMAIL], [HOST-REQ]. Als Ergebnis hat RFC2822 [IMAIL-UPDATE] numerische Offsets obligatorisch gemacht.

Numerische Offset-Berechnung​

Numerische Offsets werden als „Lokalzeit minus UTC" berechnet. Die äquivalente Zeit in UTC kann daher bestimmt werden, indem der Offset von der lokalen Zeit subtrahiert wird.

Beispiel 1:

Lokale Zeit: 18:50:00-04:00
UTC-Zeit: 18:50:00 - (-04:00) = 18:50:00 + 04:00 = 22:50:00Z

Überprüfung: Eastern Daylight Time (EDT) ist UTC-4

Beispiel 2:

Lokale Zeit: 15:30:00+08:00
UTC-Zeit: 15:30:00 - (+08:00) = 15:30:00 - 08:00 = 07:30:00Z

Überprüfung: China Standard Time (CST) ist UTC+8

Wichtige Hinweise​

Hinweis: Gemäß ISO 8601 repräsentieren numerische Offsets nur Zeitzonen, die sich von UTC um eine ganzzahlige Anzahl von Minuten unterscheiden. Viele historische Zeitzonen unterscheiden sich jedoch von UTC um eine nicht-ganzzahlige Anzahl von Minuten. Um solche historischen Zeitstempel exakt darzustellen, müssen (MUST) Anwendungen sie in eine darstellbare Zeitzone konvertieren.

Beispiele historischer Zeitzonen:

Einige lokale Zeiten im späten 19. Jahrhundert:
- Amsterdam: UTC+00:19:32
- Paris: UTC+00:09:21

Diese können in RFC 3339 nicht präzise dargestellt werden und müssen auf die nächste Minute gerundet werden

4.3. Konvention für unbekannten lokalen Offset​

Wenn die Zeit in UTC bekannt ist, aber der Offset zur lokalen Zeit unbekannt ist, kann dies mit einem Offset von "-00:00" dargestellt werden. Dies unterscheidet sich semantisch von einem Offset von "Z" oder "+00:00", was impliziert, dass UTC der bevorzugte Bezugspunkt für die angegebene Zeit ist. RFC2822 [IMAIL-UPDATE] beschreibt eine ähnliche Konvention für E-Mail.

Unterscheidung der drei Darstellungen​

Z oder +00:00:

2002-07-15T10:30:00Z
2002-07-15T10:30:00+00:00

Bedeutung: Diese Zeit IST UTC-Zeit, UTC ist der bevorzugte Bezugspunkt

-00:00:

2002-07-15T10:30:00-00:00

Bedeutung: Die UTC-Zeit ist 10:30:00, aber der lokale Zeitzonen-Offset ist unbekannt
          (möglicherweise von einem System, das seine Zeitzoneneinstellung nicht kennt)

Verwendungsszenarien:

Szenario 1: Serverprotokolle, bekanntermaßen UTC → Z verwenden
Szenario 2: Gerät-generierter Zeitstempel, Gerät ist in UTC, kennt aber lokale Zone nicht → -00:00 verwenden
Szenario 3: Explizit in London (GMT) → +00:00 verwenden

4.4. Nicht qualifizierte lokale Zeit​

Eine Anzahl von Geräten, die derzeit mit dem Internet verbunden sind, laufen mit ihren internen Uhren in lokaler Zeit und sind sich UTC nicht bewusst. Während das Internet eine Tradition hat, bei der Gestaltung von Spezifikationen die Realität zu akzeptieren, sollte dies nicht auf Kosten der Interoperabilität geschehen. Da die Interpretation einer nicht qualifizierten lokalen Zeitzone in etwa 23/24 der Welt fehlschlagen wird,

Obligatorische Anforderungen​

Internetprotokolle müssen (MUST) vollständig qualifizierte Zeitstempel generieren.

Dies bedeutet, dass Internetprotokolle lokale Zeit ohne Zeitzoneninformationen nicht (MUST NOT) verwenden dürfen.

Falsche Beispiele:

❌ 2002-07-15T10:30:00 (keine Zeitzoneninformation)

Korrekte Beispiele:

✅ 2002-07-15T10:30:00Z (UTC)
✅ 2002-07-15T10:30:00+08:00 (explizite Zeitzone)
✅ 2002-07-15T10:30:00-00:00 (UTC, aber Zone unbekannt)

Interoperabilitätsprobleme​

Wenn nicht qualifizierte lokale Zeit verwendet wird:

Sender: 2002-07-15T10:30:00 (New Yorker Lokalzeit, tatsächlich UTC-4)
Empfänger in Tokio: Interpretiert als Tokio-Zeit (UTC+9)
Zeitunterschiedsfehler: 13 Stunden!

Implementierungsempfehlungen​

Systemdesign​

# Empfohlen: Immer Zeit in UTC speichern
def store_timestamp():
    utc_time = datetime.now(timezone.utc)
    return utc_time.isoformat()  # 2024-12-21T10:30:00+00:00

# Beim Anzeigen: In lokale Zeitzone des Benutzers konvertieren
def display_timestamp(utc_time, user_timezone):
    local_time = utc_time.astimezone(user_timezone)
    return local_time.isoformat()

Datenbankspeicherung​

-- Empfohlen: TIMESTAMP WITH TIME ZONE verwenden
CREATE TABLE events (
    id SERIAL,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);

-- Vermeiden: TIMESTAMP WITHOUT TIME ZONE (verursacht Mehrdeutigkeit)

Schlüsselprinzip: Intern in UTC speichern, beim Anzeigen in lokale Zeitzone konvertieren. Niemals Zeitstempel ohne Zeitzoneninformationen für den Datenaustausch verwenden.

Letztes Update am