Zeitzone sind eine Lüge (und wie man sie in Code behandelt)

Sie öffnen eine Karte. Sie sehen vertikale Schnitte. „UTC-5 ist die Ostzeit, UTC+1 ist die zentrale europäische Zeit.“ Einfach, stimmt’s?

Falsch. Zeitzone sind eine politische Konstruktion, nicht ein geografisches Tatsache – und diese Unterscheidung wird Sie vor einigen der schlimmsten Bugs in der Softwareentwicklung bewahren.

Warum Zeitzone eigentlich ein Chaos sind

Hier ist, was Ihre Betriebssystemtz-Datenbank hinter den Kulissen für Sie verarbeitet:

• Tagesschicht (DST) — Nicht jedes Land beobachtet es, Länder ändern die Regeln, und der Wechsel erfolgt an unterschiedlichen Tagen, je nachdem wo Sie sind. Die USA wechselten 2007 die Datum. Ägypten beendete die DST 2011, stellte sie dann wieder ein, beendete sie dann erneut.
• Halbe- und Viertelstunden-Abweichungen — Indien (UTC+5:30), Nepal (UTC+5:45) und Teile Australiens (UTC+9:30) existieren. Ihre Annahme, dass Abweichungen ganze Stunden sind, ist falsch.
• Historische Änderungen — Russland wechselte 2014 von UTC+4 auf UTC+3. Samoa übersprang einen ganzen Tag (30. Dezember 2011), um von einer Seite der internationalen Datumslinie zur anderen zu wechseln. Wenn Sie mit historischen Zeitstempeln arbeiten, kann die „richtige“ Abweichung völlig anders sein als heute.
• Unklare Zeiten — Wenn die Uhren zurückgehen, tritt 1:30 Uhr zweimal auf. Wenn sie vorwärts gehen, existiert 2:30 Uhr überhaupt nicht. Wenn Sie „3. November 2024 um 1:45 Uhr Ostzeit“ ohne UTC-Abweichung speichern, haben Sie einen unklaren Zeitstempel.

Das ist keine Triviale. Jeder dieser Randfall hat echte Produkt-Bugs verursacht – verpasste Kalenderereignisse, doppelt berechnete Zahlungen, kaputte Planungssysteme.

Die eine Regel, die die meisten Probleme löst

Speichern und verarbeiten Sie immer in UTC. Konvertieren Sie nur zur Anzeigezeit in lokale Zeit.

Dies ist keine umstrittene Empfehlung. Es ist die Übereinkunft aller großen Datenbanken, API-Standard und verteilten Systemteams. Wenn Ihre Datenbankspalte 2024-11-03 06:45:00 in UTC speichert, wissen Sie immer genau, welche Zeitstelle dies darstellt – unabhängig davon, wo Ihr Server gehostet wird, in welcher Zeitzone Ihr Benutzer ist oder ob DST an diesem Tag stattfand.

Der Moment, an dem Sie 2024-11-03 01:45:00 ohne UTC-Abweichung speichern, haben Sie Informationen verloren. Sie haben einen Zeitstempel erstellt, der zwei verschiedene Bedeutungen haben kann.

Wie Zeitzone in JavaScript behandelt werden

Das integrierte Date Objekt speichert Zeit als Millisekunden seit dem Unix-Epochen (1. Januar 1970 UTC) – das ist gut. Das Problem ist, dass seine API verwirrend und inkonsistent ist.

Was zu vermeiden

// BAD: Parsing without explicit timezone
const d = new Date('2024-11-03 01:45:00');
// Interpreted as LOCAL time — behavior varies by environment

// BAD: Storing user-facing strings as dates
const meeting = '3:00 PM Thursday';
// This is meaningless without a timezone

Was stattdessen zu verwenden

// GOOD: Always use ISO 8601 with explicit UTC offset
const d = new Date('2024-11-03T06:45:00Z'); // Z = UTC

// GOOD: Display in user's local timezone using Intl API
const formatter = new Intl.DateTimeFormat('en-US', {
  timeZone: 'America/New_York',
  dateStyle: 'full',
  timeStyle: 'short',
});
console.log(formatter.format(d)); // "Sunday, November 3, 2024 at 1:45 AM"

Wenn Sie etwas über einfache Datumformatierung hinaus bauen, verwenden Sie die ist eine weitere solide Option. Moment.js ist vollständig, aber nicht mehr gepflegt – migrieren Sie davon. Bibliothek. Sie verfügt über erstklassige Zeitzone-Unterstützung, behandelt DST-Übergänge korrekt und macht die Absicht Ihres Codes offensichtlich.

import { DateTime } from 'luxon';

// Parse an ISO string and convert to a specific zone
const utc = DateTime.fromISO('2024-11-03T06:45:00Z');
const eastern = utc.setZone('America/New_York');
console.log(eastern.toLocaleString(DateTime.DATETIME_FULL));
// "November 3, 2024, 1:45 AM EDT"

Wie Zeitzone in Python behandelt werden

ohne datetime Modul unterscheidet zwischen naiv (keine Zeitzone) und bewusst (mit Zeitzone) Datumsobjekten. Naive Datumsobjekte sind ein Fußgriff – vermeiden Sie sie in jedem Code, der Zeitzonegrenzen überschreitet.

from datetime import datetime, timezone
import zoneinfo  # Python 3.9+

# BAD: naive datetime (no timezone info)
d = datetime(2024, 11, 3, 1, 45, 0)

# GOOD: always attach a timezone
d_utc = datetime(2024, 11, 3, 6, 45, 0, tzinfo=timezone.utc)

# Convert to a specific timezone
eastern = zoneinfo.ZoneInfo('America/New_York')
d_eastern = d_utc.astimezone(eastern)
print(d_eastern)  # 2024-11-03 01:45:00-05:00

Für ältere Python-Versionen oder komplexere Planungsaufgaben, python-dateutil und Pfeil sind beide gut gepflegte Optionen. Das zentrale Prinzip bleibt gleich: Arbeiten Sie in UTC, konvertieren Sie an der Grenze.

Wie Zeitzone in Datenbanken behandelt werden

Die Behandlung von Zeitzone in Datenbanken verblüfft selbst erfahrene Entwickler.

PostgreSQL

PostgreSQL hat zwei Zeitstempeltypen: timestamp (keine Zeitzone) und timestamptz (mit Zeitzone). Trotz des Namens, timestamptz speichert nicht tatsächlich die Zeitzone – es konvertiert auf Schreiben in UTC und konvertiert bei Lesen zurück in die Sitzzeitzone. Das ist das richtige Verhalten. Verwenden Sie immer timestamptz.

-- BAD
CREATE TABLE events (created_at TIMESTAMP);

-- GOOD
CREATE TABLE events (created_at TIMESTAMPTZ);

-- Querying across timezones
SELECT created_at AT TIME ZONE 'America/New_York' FROM events;

MySQL

— wandelt in die Zeitzone des MySQL-Servers um ( DATETIME die, die ohne Zeitzonekontext gespeichert werden – was Sie einlegen, wird genau so ausgegeben, ohne Konvertierung. TIMESTAMP konvertiert auf Schreiben in UTC und zurück in die aktuelle Serverzeitzone bei Lesen – aber es ist auf die Zeit zwischen 1970 und 2038 beschränkt (der Unix-Timestamp-Überlauf). In der Praxis: Verwenden Sie DATETIME Spalten und stellen Sie sicher, dass Ihre Anwendung explizit UTC-Werte schreibt.

Planung über Zeitzone: Das verborgene Problem

Stellen Sie sich vor, ein Benutzer plant eine wöchentliche Treffen für „jeden Montag um 9 Uhr New York Zeit“. Sie speichern den nächsten Zeitpunkt als UTC-Timestamp. In Ordnung – bis die DST-Änderung kommt, und jetzt entspricht der UTC-Zeitpunkt nicht mehr 9 Uhr, sondern 10 Uhr New York Zeit.

Die Lösung: Speichern Sie keine absoluten zukünftigen Zeitstempel für wiederkehrende Ereignisse. Speichern Sie die lokale Regel — die Zeitzone-Identifikation und die lokale Zeit — und berechnen Sie den nächsten UTC-Zeitstempel zur Laufzeit. Auf diese Weise wird das System korrekt nach DST-Übergängen neu berechnet.

-- Store the intent, not the absolute moment
CREATE TABLE recurring_events (
  id SERIAL PRIMARY KEY,
  timezone TEXT NOT NULL,       -- 'America/New_York'
  local_time TIME NOT NULL,     -- '09:00:00'
  recurrence TEXT NOT NULL      -- 'WEEKLY:MONDAY'
);
-- Compute next_occurrence_utc in application code at dispatch time

IANA Zeitzone-Namen vs UTC-Abweichungen

Wenn Sie eine Benutzerzeitzone vorziehen, speichern Sie den IANA-Namen (America/New_York, Europe/London, Asia/Kolkata) – nicht die UTC-Abweichung (UTC-5, UTC+1). Abweichungen sind Sichten; IANA-Namen enthalten die vollständige DST-Geschichte und zukünftigen Regeln.

America/New_York Ist UTC-5 im Winter und UTC-4 im Sommer. Wenn Sie UTC-5speichern, haben Sie die falsche Abweichung die Hälfte des Jahres eingebaut.

Schnelle Referenz: Die Regeln

• Speichern Sie Zeitstempel als UTC — immer, ohne Ausnahmen in Ihrer Datenbank oder API-Antworten.
• Verwenden Sie IANA-Zeitzone-Namen — nicht UTC-Abweichungen — für Benutzerpräferenzen und wiederkehrende Termine.
• Vermeiden Sie das Parsen von Datumzeichen ohne explizite Zeitzone — das implizite Verhalten ist umgebungabhängig.
• Konvertieren Sie zur Anzeigezeit in lokale Zeit — nicht in Ihrem Geschäftslogik oder Datenbankabfragen.
• Für wiederkehrende Termine, speichern Sie die Regel — nicht die vorkalkulierte UTC-Zeit — damit DST-Übergänge zukünftige Vorkommen nicht verfälschen.
• Testen Sie mit Randfällen — die DST-Übergangsstunde, Daten nahe der internationalen Datumslinie und historische Zeitstempel in Regionen, die ihre Abweichung geändert haben.

Das könnte Ihnen auch gefallen