Wer schon mal ein Datum in einer Datenbank gespeichert, eine API gebaut oder einen Scheduling-Bug debuggt hat, der nur in bestimmten Ländern auftrat, kennt das Problem: die Beziehung zwischen Unix-Timestamp und UTC sorgt immer wieder für Verwirrung - und echte Produktionsfehler. Dieser Artikel erklärt genau, was UTC ist, warum Unix-Timestamps per Definition UTC-basiert sind, wie Timezone-Offsets funktionieren und wie du Timestamps in JavaScript, Python und PHP korrekt konvertierst. Außerdem erfährst du, welche Fehler Entwickler am häufigsten machen und wie du sie vermeidest.
Inhaltsverzeichnis
Die wichtigsten Punkte auf einen Blick:
- Ein Unix-Timestamp zählt immer Sekunden ab dem 1. Januar 1970, 00:00:00 UTC - er enthält keine Zeitzoneinformation.
- UTC ist der universelle Referenzpunkt; Lokalzeit ist nichts anderes als UTC plus oder minus einem Offset.
- Um einen Timestamp korrekt in Lokalzeit umzuwandeln, musst du die Ziel-Timezone kennen - nicht nur einen Offset-Wert.
- DST (Sommerzeit) verändert den Offset einer Timezone, weshalb hartcodierte Offsets zu Bugs führen.
Was ist UTC und warum ist es wichtig?
UTC steht für Coordinated Universal Time (koordinierte Weltzeit). Es ist der weltweit gültige Zeitstandard, an dem sich Uhren und Zeitmessung orientieren. Anders als Zeitzonen hat UTC keinen Offset - es ist der Nullpunkt. UTC kennt keine Sommerzeit und verschiebt sich für kein Land und keine Region.
Vor UTC gab es GMT (Greenwich Mean Time), und viele verwenden beide Begriffe noch heute synonym. Technisch gesehen unterscheiden sich UTC und GMT geringfügig, für die meisten Zwecke in der Softwareentwicklung gelten sie jedoch als gleichwertig. UTC wurde formal durch die ITU-R TF.460 Empfehlung definiert und wird mithilfe von Atomuhren aufrechterhalten.
Für Entwickler ist UTC so wichtig, weil es einen einzigen, eindeutigen Referenzpunkt liefert. Wenn dein Server in Frankfurt und dein Nutzer in Los Angeles ein Ereignis jeweils in UTC aufzeichnen, kannst du die beiden Timestamps jederzeit korrekt vergleichen. Zeichnen sie es dagegen in Lokalzeit ohne Metadaten auf, hast du ein Problem.
Warum Unix-Timestamps immer UTC sind
Ein Unix-Timestamp (auch Epoch Time oder POSIX Time genannt) ist definiert als die Anzahl der Sekunden, die seit dem 1. Januar 1970, 00:00:00 UTC vergangen sind. Dieser Ankerpunkt - Mitternacht am 1. Januar 1970 in UTC - ist fest in der Definition verankert. Es gibt keine Variante von Unix Time, die in New Yorker oder Tokioter Lokalzeit beginnt.
Die Antwort auf die Frage "Ist ein Unix-Timestamp immer UTC?" lautet also: ja, per Definition. Die Zahl 1700000000 repräsentiert für jeden Menschen auf der Welt exakt denselben Moment. Was sich zwischen Nutzern unterscheidet, ist lediglich, wie dieser Moment in ihrer jeweiligen Timezone dargestellt wird.
Mehr zum grundlegenden Konzept erfährst du in unserem Artikel über Epoch Time: Die Grundlage von Unix-Timestamps.
Dieses UTC-basierte Design ist eine der nützlichsten Eigenschaften von Unix Time. Da die Zahl selbst keine Zeitzoneinformation trägt, können zwei Systeme in verschiedenen Ländern einen Timestamp austauschen und beide wissen genau, welchen Moment er bezeichnet - ohne zusätzliche Absprachen.
UTC vs. Lokalzeit und Zeitzonen
UTC ist die Referenz. Lokalzeit erhältst du, wenn du eine Zeitzonenregel darauf anwendest. Eine Timezone ist nicht einfach ein fester Offset - sie ist eine benannte Region mit einem Regelwerk, das sich im Laufe der Zeit ändern kann (hauptsächlich wegen der Sommerzeit).
Die "Eastern Time" in den USA ist zum Beispiel UTC-5 im Winter und UTC-4 im Sommer. Der Timezone-Name lautet "America/New_York" in der IANA-Timezone-Datenbank, der maßgeblichen Quelle für Zeitzonenregeln, die von den meisten Programmiersprachen und Betriebssystemen genutzt wird.
Die praktische Konsequenz: Wenn du einen Unix-Timestamp in deiner Datenbank speicherst, speicherst du einen UTC-Wert. Bei der Anzeige für Nutzer konvertierst du ihn in deren Lokalzeit. Speichere niemals Lokalzeit als rohe Zahl und gehe davon aus, dass sie UTC ist - genau dort entstehen Bugs.
Wie UTC-Offsets funktionieren
Ein UTC-Offset beschreibt, wie weit eine Timezone von UTC entfernt ist. Er wird als +HH:MM oder -HH:MM angegeben. Einige Beispiele:
- UTC+02:00 - Mitteleuropäische Sommerzeit (CEST), genutzt in Deutschland und Frankreich im Sommer.
- UTC-05:00 - Eastern Standard Time (EST), genutzt an der US-Ostküste im Winter.
- UTC+05:30 - India Standard Time (IST), ein halbstündiger Offset.
- UTC+00:00 - UTC selbst, im Winter auch vom Vereinigten Königreich genutzt (GMT).
Um eine UTC Epoch Time manuell in Lokalzeit umzurechnen, addierst oder subtrahierst du den Offset in Sekunden. Für UTC+02:00 sind das 2 * 3600 = 7200 Sekunden. Wenn dein Unix-Timestamp also 1700000000 ist, entspricht die Lokalzeit in UTC+02:00 dem Wert 1700000000 + 7200 vor der Formatierung.
Dieses manuelle Vorgehen ist jedoch riskant, weil sich Offsets durch die Sommerzeit ändern. Verwende immer eine geeignete Timezone-Bibliothek, anstatt Offsets hartzucodieren. Einen tieferen Einblick in Konvertierungsmethoden findest du in unserem Leitfaden Unix-Timestamp in Datum umrechnen.
Unix-Timestamps in Lokalzeit umrechnen
Hier ist ein konkretes Beispiel mit dem Unix-Timestamp 1700000000, der dem 14. November 2023, 22:13:20 UTC entspricht. Wir konvertieren ihn in drei Sprachen nach "America/New_York" (UTC-5 im November).
JavaScript
const ts = 1700000000;
// JavaScript Date erwartet Millisekunden
const date = new Date(ts * 1000);
// Anzeige in New Yorker Lokalzeit
const options = {
timeZone: 'America/New_York',
year: 'numeric',
month: 'long',
day: 'numeric',
hour: '2-digit',
minute: '2-digit',
second: '2-digit',
timeZoneName: 'short'
};
console.log(date.toLocaleString('en-US', options));
// Output: November 14, 2023 at 05:13:20 PM ESTBeachte, dass das Date-Objekt in JavaScript die Zeit intern als UTC-Millisekunden speichert. Die Methode toLocaleString mit einer timeZone-Option übernimmt Offset und DST-Regeln automatisch für dich.
Python
from datetime import datetime, timezone
import zoneinfo # Python 3.9+
ts = 1700000000
# UTC-bewusstes datetime-Objekt aus dem Timestamp erstellen
utc_dt = datetime.fromtimestamp(ts, tz=timezone.utc)
# In New Yorker Lokalzeit konvertieren
ny_tz = zoneinfo.ZoneInfo('America/New_York')
local_dt = utc_dt.astimezone(ny_tz)
print(local_dt.strftime('%Y-%m-%d %H:%M:%S %Z'))
# Output: 2023-11-14 17:13:20 ESTEntscheidend ist hier die Verwendung von datetime.fromtimestamp(ts, tz=timezone.utc). Lässt du das tz-Argument weg, nutzt Python die lokale Timezone des Servers zur Interpretation des Timestamps - eine häufige Fehlerquelle.
PHP
$ts = 1700000000;
// DateTime-Objekt aus Unix-Timestamp erstellen (immer UTC)
$dt = new DateTime('@' . $ts);
// Ziel-Timezone setzen
$dt->setTimezone(new DateTimeZone('America/New_York'));
echo $dt->format('Y-m-d H:i:s T');
// Output: 2023-11-14 17:13:20 ESTIn PHP signalisiert das @-Präfix beim Erstellen eines DateTime-Objekts, dass der Wert als Unix-Timestamp (UTC) behandelt werden soll. Ohne dieses Präfix kann PHP den String anhand der Standard-Timezone-Einstellung des Servers interpretieren.
Typische Fehler bei der Zeitzonenbehandlung
Selbst erfahrene Entwickler stolpern über Timezone-Probleme. Hier sind die häufigsten Fehler:
1. Annehmen, dass die Serverzeit UTC ist
Wenn dein Server auf "Europe/Berlin" eingestellt ist und du time() in PHP oder datetime.now() in Python ohne Timezone-Argument aufrufst, erhältst du Lokalzeit - nicht UTC. Sei beim Aufzeichnen von Timestamps immer explizit in Bezug auf UTC.
2. UTC-Offsets hartzucodieren statt Timezone-Namen zu verwenden
+02:00 als festen Offset für Deutschland zu verwenden, führt im Winter zu Fehlern, wenn Deutschland auf +01:00 wechselt. Verwende immer benannte Zeitzonen wie Europe/Berlin, damit die Bibliothek die korrekten DST-Regeln automatisch anwenden kann.
3. Timestamps als Lokalzeit-Strings ohne Timezone-Metadaten speichern
Ein String wie 2023-11-14 17:13:20 in einer Datenbank ist mehrdeutig. Ist das UTC? EST? IST? Wenn du Timestamps als Unix-Integer oder als ISO 8601-String mit UTC-Offset speicherst (z. B. 2023-11-14T22:13:20Z), ist die Bedeutung eindeutig. Unser Vergleich von Unix-Timestamp-Format vs. ISO 8601 hilft dir bei der Entscheidung.
4. DST beim Scheduling ignorieren
Wenn du einen Job so planst, dass er "täglich um 09:00 Uhr" läuft, indem du jeweils 86400 Sekunden zur letzten Ausführungszeit addierst, verschiebt er sich an den Tagen, an denen die Sommerzeit wechselt, um eine Stunde. Nutze eine Cron-Bibliothek oder einen Scheduler, der Timezone-Regeln versteht.
5. Millisekunden und Sekunden verwechseln
JavaScript verwendet Millisekunden für sein Date-Objekt, die meisten Unix-Timestamps sind jedoch in Sekunden angegeben. Wenn du einen sekundenbasierten Timestamp ohne Multiplikation mit 1000 an new Date() übergibst, erhältst du ein Datum im Januar 1970. Details dazu findest du in unserem Artikel über Sekunden vs. Millisekunden vs. Mikrosekunden.
Fazit
Unix-Timestamps und UTC sind konzeptionell untrennbar miteinander verbunden. Ein Timestamp ist immer ein UTC-Wert - eine Sekundenanzahl ab einem festen UTC-Ankerpunkt. Lokalzeit ist lediglich ein Anzeigeformat, keine andere Art von Timestamp. Die sicherste Vorgehensweise: alles als UTC speichern, in Lokalzeit nur zum Zeitpunkt der Anzeige konvertieren und immer benannte Zeitzonen statt hartcodierter Offsets verwenden. Wer diese Regeln befolgt, vermeidet den Großteil aller zeitzonenbedingten Bugs. Best Practices zur Speicherung dieser Werte findest du in unserem Leitfaden Unix-Timestamps in Datenbanken.
Jeden Unix-Timestamp sofort in UTC oder Lokalzeit umrechnen
Füge einen beliebigen Unix-Timestamp ein und sieh ihn mit einem Klick in UTC und deiner Lokalzeit. Kostenlos, ohne Registrierung, funktioniert mit Sekunden und Millisekunden.
Jetzt kostenloses Tool ausprobieren →
Ja. Per Definition zählt ein Unix-Epoch-Timestamp Sekunden ab dem 1. Januar 1970, 00:00:00 UTC. Die Zahl selbst enthält keine Timezone - sie ist ein UTC-Wert. Eine Timezone wird erst relevant, wenn du den Timestamp für die Anzeige in ein lesbares Datum und eine Uhrzeit umwandelst.
Nutze die integrierte Timezone-Bibliothek deiner Programmiersprache. In JavaScript verwendest du toLocaleString mit einer timeZone-Option. In Python nutzt du datetime.fromtimestamp(ts, tz=timezone.utc).astimezone() mit einer benannten Timezone. In PHP erstellst du ein DateTime-Objekt aus dem Timestamp und rufst setTimezone() auf. Verwende immer benannte Zeitzonen, keine rohen Offsets.
Das passiert meistens, weil eine Funktion die Standard-Timezone des Servers statt UTC zur Interpretation des Timestamps verwendet. In Python führt das Weglassen des tz-Arguments bei datetime.fromtimestamp() zur Nutzung der lokalen Systemzeit. In PHP hat das Fehlen des @-Präfixes denselben Effekt. Sei beim Erstellen von Timestamps immer explizit in Bezug auf UTC.
Ein UTC-Offset ist die Anzahl der Stunden (und manchmal Minuten), um die eine Timezone vor oder hinter UTC liegt. Zum Beispiel liegt UTC-05:00 fünf Stunden hinter UTC. Bei der Umrechnung eines Unix-Timestamps in Lokalzeit wird der Offset auf den UTC-Wert angewendet. Da sich Offsets durch die Sommerzeit ändern, solltest du immer eine benannte Timezone statt eines hartcodierten Offsets verwenden.
Ja, und das ist einer der größten Vorteile von Unix-Timestamps. Da jeder Timestamp ein UTC-Wert ist, kannst du zwei beliebige Timestamps direkt als Integer vergleichen. Eine höhere Zahl bedeutet immer einen späteren Zeitpunkt, unabhängig davon, wo die Timestamps erzeugt wurden. Für den Vergleich ist keine Timezone-Konvertierung erforderlich.