Warum du Zeitzonenabkürzungen wie EST oder PST im Code niemals verwenden solltest

EST, PST, CST, IST – das sieht nach Zeitzonen aus. Sind es aber nicht. Es sind informelle Kurzbezeichnungen, die von Bibliotheken, Sprachen und Ländern unterschiedlich interpretiert werden. Wer sie im Code verwendet, produziert Scheduling-Bugs, die zweimal im Jahr zur DST-Umstellung in der Produktion auftauchen.

Warum Abkürzungen versagen

Sie sind mehrdeutig. IST allein kann bedeuten:

• India Standard Time (UTC+5:30)
• Ireland Standard Time (UTC+1)
• Israel Standard Time (UTC+2)

CST kann US Central Standard Time (UTC−6), China Standard Time (UTC+8), Cuba Standard Time (UTC−5) oder Australian Central Standard Time (UTC+9:30) sein.

Wenn deine Datumsbibliothek auf CST trifft, wählt sie eine davon. Welche, hängt von der Bibliothek, ihrer Version und manchmal dem System-Locale ab. Dass sie die falsche gewählt hat, merkst du oft erst, wenn ein Scheduling-Bug in der Produktion auftaucht – zu einem Zeitpunkt, an dem der Fehler schon eine Weile still vorhanden war.

Sie kodieren keine Sommerzeit. EST ist UTC−5, aber New York im Sommer ist EDT (UTC−4). Wenn du 2026-06-20 15:00 EST parst und als UTC−5 behandelst, liegst du eine Stunde daneben. Manche Bibliotheken korrigieren das still. Viele nicht.

Sie haben keinen Standard. Anders als IANA-Zonennamen gibt es für Abkürzungen keine verbindliche Spezifikation. Verschiedene Systeme interpretieren denselben String unterschiedlich.

Was du stattdessen verwenden solltest

IANA-Zonennamen sind der richtige Weg, eine Zeitzone im Code zu identifizieren:

IANA-Namen kodieren die vollständige DST-Geschichte. America/New_York weiß, dass New York im Winter UTC−5 und im Sommer UTC−4 ist – und an welchen genauen Daten die Umstellungen stattfinden.

In der Praxis

JavaScript:

// Schlecht
new Date("2026-06-20 15:00 EST"); // mehrdeutig, bibliotheksabhängig

// Gut
const dt = new Temporal.ZonedDateTime(
  Temporal.PlainDateTime.from("2026-06-20T15:00"),
  "America/New_York",
);

Python:

# Schlecht
datetime.strptime('2026-06-20 15:00 EST', '%Y-%m-%d %H:%M %Z')  # unzuverlässig

# Gut
from zoneinfo import ZoneInfo
from datetime import datetime
dt = datetime(2026, 6, 20, 15, 0, tzinfo=ZoneInfo('America/New_York'))

PostgreSQL:

-- Schlecht: reinen Timestamp speichern
INSERT INTO events (start_time) VALUES ('2026-06-20 15:00:00');

-- Gut: UTC speichern, Zonenname in separater Spalte
INSERT INTO events (start_time_utc, user_timezone)
VALUES ('2026-06-20 19:00:00+00', 'America/New_York');

Wenn Abkürzungen von außen ankommen

Du kannst nicht immer kontrollieren, was reinkommt. Wenn du einen Zeitstring mit einer Abkürzung aus Benutzereingaben oder einer externen API bekommst, behandle ihn als nicht vertrauenswürdig:

1. Hole die IANA-Zone des Benutzers aus dem Browser: Intl.DateTimeFormat().resolvedOptions().timeZone
2. Bilde mehrdeutige Abkürzungen per Lookup-Table auf IANA-Namen ab – und markiere wirklich mehrdeutige Fälle (wie IST) statt zu raten
3. Geh niemals stillschweigend davon aus, dass die Bibliothek die Abkürzung korrekt aufgelöst hat

Erzwinge IANA-Namen an Eingabegrenzen, und du vermeidest die gesamte Klasse DST-bedingter Scheduling-Bugs.