0Pricing
Coding Interview Prep · Lektion

Zeitzonen und Zeitstempel

UTC speichern, Zeitzonen umrechnen und typische Interviewfragen zu Zeitstempeln verstehen.

Zeitzonen und Zeitstempel ist eine kostenlose Coding Interview Prep-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Coding Interview Prep-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Coding Interview Prep-Kurs umfasst insgesamt 4 Lektionen.

Warum Zeitzonen Kandidaten ins Stolpern bringen

Bei Zeitzonen kommen selbst selbstbewusste Kandidaten ins Stolpern. Deshalb fragen Interviewer sie ab, um festzustellen, wie tief das Verständnis reicht. Die zentrale Frage lautet immer: „Wie speichern und vergleichen Sie Zeitstempel über verschiedene Regionen hinweg?“

Die professionelle Antwort ist keine einzelne Funktion, sondern eine Vorgehensweise: Speichern Sie alles in UTC und rechnen Sie nur an den Schnittstellen zur Anzeige in die lokale Zeitzone um. Wenn das Speichermodell stimmt, werden die meisten Abfragen trivial.

  • timestamp vs timestamptz
  • Zwischen Zeitzonen umrechnen
  • UTC als Referenzquelle

timestamp vs timestamptz

PostgreSQL hat zwei Zeitstempeltypen. Sie zu verwechseln, ist ein typischer Fehler im Interview.

  • timestamp (ohne Zeitzone): ein Wanduhrzeitwert ohne angehängte Zeitzone. Gespeichert wird genau der Wert, den Sie angeben.
  • timestamptz (mit Zeitzone): wird intern als UTC gespeichert; bei der Eingabe wird der Wert aus der Sitzungszeitzone umgerechnet, bei der Ausgabe wieder zurück.

Trotz seines Namens speichert timestamptz keine Zeitzone, sondern einen eindeutigen Zeitpunkt in UTC. Dieses Detail beeindruckt Interviewer.

CREATE TABLE events (
  id          bigint,
  occurred_at timestamptz   -- recommended: an absolute instant
);

UTC speichern, an den Systemgrenzen umrechnen

Die wichtigste Grundregel: Speichern Sie Zeitpunkte in UTC (verwenden Sie timestamptz) und rechnen Sie sie erst bei der Darstellung für Benutzer in eine lokale Zeitzone um. Dadurch vermeiden Sie Mehrdeutigkeiten bei der Sommerzeit, und eine zeitliche Sortierung funktioniert überall korrekt.

Wenn Sie gefragt werden „Warum UTC?“, antworten Sie: UTC kennt keine Umstellungen auf Sommerzeit. Daher tritt derselbe Wanduhrzeitwert nie zweimal auf und wird auch nicht übersprungen – anders als bei der Ortszeit.

-- Display a UTC instant in a user's zone (Postgres)
SELECT occurred_at AT TIME ZONE 'America/New_York' AS local_time
FROM events;

Die doppelte Bedeutung von AT TIME ZONE

AT TIME ZONE ist raffiniert und eine häufige Fehlerquelle, weil es je nach Eingabetyp zwei entgegengesetzte Dinge tut:

  • Angewendet auf einen timestamptz wandelt es den absoluten Zeitpunkt in diese Zeitzone um und gibt einen einfachen timestamp zurück (die dortige Uhrzeit).
  • Angewendet auf einen einfachen timestamp interpretiert es diese Uhrzeit als Uhrzeit in dieser Zeitzone und gibt einen timestamptz zurück.

Der entscheidende Kniff besteht darin, zu wissen, in welche Richtung die Umwandlung erfolgt.

-- timestamptz -> local wall clock (returns timestamp)
SELECT TIMESTAMPTZ '2024-03-01 12:00:00+00'
         AT TIME ZONE 'Asia/Tokyo';        -- 2024-03-01 21:00:00

-- plain timestamp interpreted in a zone (returns timestamptz)
SELECT TIMESTAMP '2024-03-01 12:00:00'
         AT TIME ZONE 'Asia/Tokyo';        -- 2024-03-01 03:00:00+00

Den aktuellen Zeitpunkt ermitteln

Kennen Sie die Funktionen für „jetzt“. NOW() und CURRENT_TIMESTAMP geben in Postgres einen timestamptz zurück. Sie liefern die Uhrzeit zum Beginn der Transaktion, nicht zum Beginn des Statements. Das ist bei langen Transaktionen wichtig.

Für UTC können Sie die Umwandlung ausdrücklich vornehmen: NOW() AT TIME ZONE 'UTC'. In MySQL liefert UTC_TIMESTAMP() UTC direkt.

SELECT
  NOW()                       AS tx_start_tz,
  NOW() AT TIME ZONE 'UTC'    AS utc_walltime;

Die Sommerzeit ist der eigentliche Gegner

Interviewer lieben Randfälle rund um die Sommerzeit. Wenn die Uhren vorgestellt werden, existiert eine lokale Stunde nicht; wenn sie zurückgestellt werden, wiederholt sich eine Stunde. Das Speichern der lokalen Uhrzeit macht diese Fälle mehrdeutig oder ungültig.

Das Speichern von UTC umgeht dieses Problem vollständig: Jeder Zeitpunkt ist eindeutig und monoton steigend. Wenn Sie eine Region wie 'America/New_York' angeben (nicht einen festen Offset wie -05:00), kann die Datenbank die Sommerzeitregeln für jedes Datum korrekt anwenden.

-- Region name applies DST automatically for the given date
SELECT TIMESTAMPTZ '2024-07-01 12:00:00+00'
         AT TIME ZONE 'America/New_York' AS summer, -- EDT (-04)
       TIMESTAMPTZ '2024-01-01 12:00:00+00'
         AT TIME ZONE 'America/New_York' AS winter; -- EST (-05)

Nach lokalem Tag über mehrere Zeitzonen gruppieren

Ein realistisches Problem: „täglich aktive Nutzer in der lokalen Zeit jedes Nutzers“. Wenn Sie den UTC-Zeitstempel direkt auf den Tag kürzen, liegen die Mitternachtsgrenzen für Nutzer außerhalb von UTC falsch.

Wandeln Sie den Zeitstempel vor dem Kürzen auf den Tag in die Zeitzone des Nutzers um. Die Umwandlung verschiebt die Uhrzeit so, dass die Tagesgrenzen lokal korrekt ausgerichtet sind.

SELECT
  DATE_TRUNC('day', occurred_at AT TIME ZONE u.tz) AS local_day,
  COUNT(DISTINCT e.user_id)                         AS dau
FROM events e
JOIN users u ON u.id = e.user_id
GROUP BY 1
ORDER BY 1;

Zeitstempel sicher vergleichen

Wenn Sie nach einer timestamptz-Spalte filtern, vergleichen Sie sie mit einem expliziten Zeitpunkt, idealerweise einem UTC-Literal oder einem timestamptz mit Offset. Ein nicht näher qualifizierter String kann in der unvorhersehbaren Zeitzone der Sitzung interpretiert werden.

So bleibt der Vergleich unabhängig davon eindeutig, wer die Abfrage ausführt.

SELECT *
FROM events
WHERE occurred_at >= TIMESTAMPTZ '2024-03-01 00:00:00+00'
  AND occurred_at <  TIMESTAMPTZ '2024-04-01 00:00:00+00';

Epoch- und Unix-Zeitstempel

Viele Systeme speichern Zeit als Unix-Epoch (Sekunden seit dem 01.01.1970 UTC). Interviewer geben Ihnen möglicherweise eine Spalte mit Ganzzahlen und bitten Sie, diese zu interpretieren.

  • Postgres: TO_TIMESTAMP(epoch_seconds) gibt einen timestamptz zurück.
  • Zurück zur Epoch-Zeit: EXTRACT(EPOCH FROM occurred_at).
  • MySQL: FROM_UNIXTIME() und UNIX_TIMESTAMP().

Epoch-Werte sind grundsätzlich UTC-Werte. Das ist ein Grund für ihre große Verbreitung bei der Speicherung.

SELECT
  TO_TIMESTAMP(1709294400)               AS as_ts,   -- from epoch
  EXTRACT(EPOCH FROM NOW())::bigint        AS as_epoch; -- to epoch

Zeitzonenhinweise für verschiedene SQL-Dialekte

Eine kurze Übersicht, damit Sie in jeder Umgebung sicher wirken:

  • Postgres: timestamptz und AT TIME ZONE bieten die umfassendste Unterstützung.
  • MySQL: TIMESTAMP wird automatisch über die Sitzungsoption time_zone umgewandelt; CONVERT_TZ(t, from, to) wandelt explizit um. DATETIME berücksichtigt keine Zeitzone.
  • SQL Server: datetimeoffset speichert einen Offset; AT TIME ZONE 'name' wandelt mithilfe von Windows-Zeitzonennamen um.
-- MySQL explicit conversion
SELECT CONVERT_TZ(event_dt, 'UTC', 'Europe/Istanbul') AS local_dt
FROM events;

Tiefergehendes Beispiel: Sitzungen über Mitternacht hinweg

Eine subtile Frage zur Berichterstellung: Zählen Sie Sitzungen pro lokalem Kalendertag, wenn eine Sitzung über Mitternacht hinausgehen kann. Die Lösung folgt derselben Disziplin: in die lokale Zeit umwandeln und anschließend gruppieren.

Speichern Sie Beginn und Ende als timestamptz; leiten Sie für die Auswertung den lokalen Tag aus dem umgewandelten Beginn ab. Wenn eine Sitzung auf zwei Tage aufgeteilt werden muss, würden Sie eine Tageskalendertabelle (Day Spine) verknüpfen. Das ist ein guter Punkt für eine weiterführende Frage.

SELECT
  DATE_TRUNC('day', started_at AT TIME ZONE 'Europe/Istanbul') AS local_day,
  COUNT(*) AS sessions
FROM sessions
GROUP BY 1
ORDER BY 1;

Kurzer Wissenscheck

Bestätigen Sie die empfohlene Speicherstrategie und begründen Sie sie.

Zusammenfassung: Zeitzonen und Zeitstempel

Diese Vorgehensweise sollten Sie mitnehmen:

  • Speichern Sie UTC als timestamptz; wandeln Sie nur für die Anzeige in eine benannte Zeitzone um.
  • timestamptz speichert einen UTC-Zeitpunkt, keine Zeitzone, trotz seines Namens.
  • AT TIME ZONE funktioniert abhängig vom Eingabetyp in beide Richtungen: Es wandelt einen timestamptz in eine lokale Uhrzeit um oder interpretiert einen einfachen timestamp als Uhrzeit in einer Zeitzone.
  • Verwenden Sie Regionsnamen wie 'America/New_York', damit die Sommerzeit automatisch angewendet wird, und vermeiden Sie feste Offsets.
  • Wandeln Sie vor dem Kürzen auf den Tag in die lokale Zeit um und vergleichen Sie Spalten mit expliziten UTC-Zeitpunkten.

Häufig gestellte Fragen

Ist die Lektion „Zeitzonen und Zeitstempel“ kostenlos?

Ja — der vollständige Text von „Zeitzonen und Zeitstempel“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Coding Interview Prep-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Coding Interview Prep-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Zeitzonen und Zeitstempel“?

UTC speichern, Zeitzonen umrechnen und typische Interviewfragen zu Zeitstempeln verstehen. Du übst Coding Interview Prep mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Coding Interview Prep zu starten?

Keine Vorkenntnisse erforderlich. Coding Interview Prep auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „Zeitzonen und Zeitstempel“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Coding Interview Prep-Lektion Code schreiben und ausführen?

Ja. Jede Coding Interview Prep-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. Datumsarithmetik und Intervalle
  2. Datumsangaben abschneiden und gruppieren
  3. Zeichenfolgen analysieren und formatieren
  4. Zeitzonen und Zeitstempel
← Zurück zu Coding Interview Prep