Unix-Zeit in Datum — beliebige Epoch in ein lesbares Datum umwandeln

Unix-Zeit in Datum in einer Zeile

Hier ist die ganze Aufgabe an einem Beispiel: Der Unix-Timestamp 1700000000 wird zu 2023-11-14T22:13:20Z — Dienstag, 14. November 2023 um 22:13:20 UTC. Ein Unix-Timestamp zählt Sekunden seit dem 1.1.1970 UTC; ihn umzuwandeln bedeutet also, diese Zählung als UTC zu dekodieren und in der gewünschten Zeitzone zu formatieren. Das Einzige, was Umwandlungen zerstört, ist die Einheit: 10 Stellen sind Sekunden, 13 Millisekunden, 16 Mikrosekunden. Die folgende Tabelle ist der zum Kopieren bereite Einzeiler für jede Sprache und jedes Tool in dieser Anleitung.

• Den Unix-Timestamp-Konverter öffnen
• In die andere Richtung — Datum in Unix-Timestamp

Was Unix-Zeit zu Datum bedeutet

Ein Unix-Timestamp ist die Anzahl der Sekunden seit dem 1.1.1970 UTC. Um ihn in ein Datum umzuwandeln, dekodierst du ihn als UTC und formatierst ihn dann in einer beliebigen Zeitzone. Das ist das gesamte Problem in einem Satz — der Rest dieser Anleitung ist nur die Syntax in jeder Sprache. Jede moderne Programmiersprache bringt eine eingebaute Funktion mit, die einen Unix-Epoch-Wert entgegennimmt und ein Datumsobjekt zurückgibt; das Einzige, worauf du achten musst, ist, ob die Sprache Sekunden (Python, PHP, Linux date), Millisekunden (JavaScript Date) oder Mikrosekunden (PostgreSQL, BigQuery) erwartet.

Die schnelle Umwandlungsregel

Zähle die Stellen deines Werts. Eine 10-stellige Zahl ist in Unix-Sekunden. Eine 13-stellige Zahl ist in Unix-Millisekunden. Eine 16-stellige Zahl ist in Unix-Mikrosekunden. Die Unix-Epoch begann am 1.1.1970 — daher beginnen 10-stellige Werte heute (2026) mit 17 oder 18; Millisekunden beginnen mit 175 oder 176, gefolgt von 10 Ziffern; Mikrosekunden beginnen mit 1758 oder 1759. Erkenne die Einheit, bevor du den Wert an eine Umwandlungsfunktion übergibst, dann landet deine Ausgabe am richtigen Tag statt im Jahr 1970.

• 10 Stellen → Unix-Sekunden (Bereich 2001 bis 2286)
• 13 Stellen → Unix-Millisekunden (Bereich 2001 bis 2286)
• 16 Stellen → Unix-Mikrosekunden (Bereich 2001 bis 2286)
• Zahlen nahe 10^9 (1.000.000.000) sind Sekunden vor 2001 — weiterhin gültige Unix-Zeit
• Negative ganze Zahlen sind Daten vor 1970 — die meisten Sprachen verarbeiten sie; prüfen
• Zahlen über 2^31 in INT-Spalten erreichen das Jahr-2038-Limit — siehe unten

• Millisekunden vs. Sekunden — der vollständige Einheiten-Guide

Unix-Zeit in ein Datum in JavaScript umwandeln

Der Date-Konstruktor von JavaScript erwartet Millisekunden, daher muss ein Unix-Sekunden-Wert zuerst mit 1000 multipliziert werden. Das Ergebnis ist ein Date-Objekt; formatiere es mit toISOString() für ISO 8601 in UTC oder mit Intl.DateTimeFormat für eine zeitzonenbewusste, menschenlesbare Zeichenkette. Gib immer eine explizite timeZone-Option an — ohne sie verwendet JavaScript die lokale Zeitzone der Laufzeitumgebung, die sich zwischen Entwickler-Laptops und Produktionsservern unterscheidet.

• new Date(1700000000 * 1000).toISOString() // '2023-11-14T22:13:20.000Z'
• new Date(1700000000 * 1000).toLocaleString('en-US', { timeZone: 'America/New_York' }) // tz-aware
• new Date(1700000000000).toISOString() // milliseconds — no × 1000 needed
• new Intl.DateTimeFormat('en-US', { timeZone: 'Asia/Tokyo', dateStyle: 'full', timeStyle: 'long' }).format(new Date(ms))
• Detect unit at runtime: const toDate = ts => new Date(ts < 1e11 ? ts * 1000 : ts)

• MDN — Date()-Konstruktor
• Zeitzonenkorrekte Datumsformatierung in JavaScript (Begleitartikel)

Unix-Zeit in ein Datum in Python umwandeln

datetime.fromtimestamp(ts, tz=timezone.utc) ist die kanonische Umwandlung in Python. Das tz-Argument ist für ein UTC-Ergebnis erforderlich; ohne es liefert Python den Timestamp in der lokalen Zeitzone des Systems — eine häufige Quelle von Zeitzonen-Drift-Fehlern auf Servern. utcfromtimestamp() ist seit Python 3.12 veraltet, weil es ein naives datetime zurückgab, das leicht falsch verwendet werden konnte. Für Millisekunden teile durch 1000; für Mikrosekunden durch 1.000.000 — Python akzeptiert Sekundenbruchteile direkt.

• from datetime import datetime, timezone
• datetime.fromtimestamp(1700000000, tz=timezone.utc) # 2023-11-14 22:13:20+00:00
• datetime.fromtimestamp(1700000000.123, tz=timezone.utc) # fractional seconds work
• datetime.fromtimestamp(ms / 1000, tz=timezone.utc) # from milliseconds
• datetime.fromtimestamp(us / 1_000_000, tz=timezone.utc) # from microseconds
• Avoid: datetime.utcfromtimestamp(ts) — deprecated in 3.12; returns naive datetime

• Python — datetime.fromtimestamp

Unix-Zeit in ein Datum in PHP umwandeln

gmdate(format, timestamp) in PHP liefert eine UTC-Datumszeichenkette für die angegebenen Unix-Sekunden; date(format, timestamp) liefert denselben Zeitpunkt in der lokalen Zeitzone des Servers (gesteuert über date_default_timezone_set oder php.ini). Die Klasse DateTime mit DateTimeZone bietet die moderne, unveränderliche API und unterstützt beliebige IANA-Zeitzonennamen. PHP arbeitet standardmäßig in Sekunden, also teile Millisekundenwerte zuerst durch 1000.

• gmdate('c', 1700000000) // '2023-11-14T22:13:20+00:00' (UTC ISO 8601)
• date('Y-m-d H:i:s', 1700000000) // server-local — depends on date.timezone setting
• new DateTime('@1700000000') // immutable, UTC by default with the @ prefix
• (new DateTime('@1700000000'))->setTimezone(new DateTimeZone('Asia/Tokyo'))->format('c')
• DateTime::createFromFormat('U.u', '1700000000.123456') // sub-second precision

• PHP — gmdate()-Referenz

Unix-Zeit in ein Datum in Java umwandeln

Die java.time-API von Java (Java 8+) wandelt Unix-Sekunden mit Instant.ofEpochSecond(s) um, das einen UTC-Instant zurückgibt — Instant ist immer UTC, es gibt also keine versteckte Überraschung mit der lokalen Zeitzone. Verwende Instant.ofEpochMilli(ms) für Millisekunden-Eingaben, hänge mit atZone(ZoneId.of(...)) eine Zone für eine Wanduhr-Darstellung an und formatiere mit DateTimeFormatter. Der veraltete java.util.Date-Konstruktor erwartet Millisekunden, wie JavaScript — multipliziere Sekunden zuerst mit 1000L.

• Instant.ofEpochSecond(1700000000) // 2023-11-14T22:13:20Z (UTC)
• Instant.ofEpochMilli(1700000000000L) // from milliseconds
• Instant.ofEpochSecond(1700000000).atZone(ZoneId.of("Asia/Tokyo")) // tz-aware
• DateTimeFormatter.ISO_INSTANT.format(Instant.ofEpochSecond(s)) // ISO 8601
• new java.util.Date(1700000000L * 1000) // legacy API — expects milliseconds

• Unix-Timestamps in Java — vollständige Referenz

Unix-Zeit in ein Datum in C# (.NET) umwandeln

In .NET ist DateTimeOffset.FromUnixTimeSeconds(s) die moderne Umwandlung — sie gibt ein DateTimeOffset zurück, das an UTC (+00:00) verankert ist. Verwende FromUnixTimeMilliseconds(ms) für Millisekunden-Eingaben. Lies .UtcDateTime für ein UTC-DateTime oder konvertiere mit TimeZoneInfo.ConvertTime in eine bestimmte Zone. Formatiere mit dem Roundtrip-Spezifizierer "o" für ISO 8601. Die eingebauten Unix-Methoden (hinzugefügt in .NET 4.6) übernehmen die Epoch-Berechnung, vermeide also das alte DateTime.AddSeconds-ab-1970-Muster.

• DateTimeOffset.FromUnixTimeSeconds(1700000000) // 2023-11-14 22:13:20 +00:00
• DateTimeOffset.FromUnixTimeMilliseconds(1700000000000) // from milliseconds
• DateTimeOffset.FromUnixTimeSeconds(s).UtcDateTime // DateTime in UTC
• TimeZoneInfo.ConvertTime(dto, tzInfo) // tz-aware rendering
• DateTimeOffset.FromUnixTimeSeconds(s).ToString("o") // ISO 8601 round-trip

• Unix-Timestamps in C# — vollständige Referenz

Unix-Zeit in ein Datum in Go umwandeln

time.Unix(sec, nsec) in Go erstellt ein Time aus Unix-Sekunden (plus optionalen Nanosekunden), gibt den Wert aber in der lokalen Zeitzone zurück — rufe .UTC() auf, um ihn zu verankern. Go 1.17 fügte time.UnixMilli(ms) und time.UnixMicro(us) hinzu, sodass du nicht mehr von Hand teilst. Formatiere mit der RFC3339-Konstante für ISO 8601 und verwende .In(loc) mit time.LoadLocation für eine bestimmte Zone.

• time.Unix(1700000000, 0).UTC() // 2023-11-14 22:13:20 +0000 UTC
• time.UnixMilli(1700000000000).UTC() // from milliseconds (Go 1.17+)
• time.UnixMicro(1700000000000000).UTC() // from microseconds (Go 1.17+)
• time.Unix(1700000000, 0).Format(time.RFC3339) // ISO 8601 string
• time.Unix(s, 0).In(loc) // tz-aware; loc from time.LoadLocation

• Unix-Timestamps in Go — vollständige Referenz

Unix-Zeit in ein Datum in der Shell umwandeln (Linux / macOS)

Unter Linux verwendet der GNU-Befehl date -d @ts zur Umwandlung von Unix-Sekunden; unter macOS verwendet der BSD-Befehl date -r ts für dieselbe Aufgabe. Die Flags unterscheiden sich je nach historischer Implementierung — die eigentliche Epoch-Berechnung ist identisch. Das Flag -u erzwingt UTC-Ausgabe unabhängig von der Umgebungsvariable TZ. Beide Implementierungen unterstützen beliebige Ausgabeformate über das Argument +%FORMAT; die nützlichsten Formatzeichenketten sind unten zusammengefasst.

• GNU (Linux): date -u -d @1700000000 // 'Tue Nov 14 22:13:20 UTC 2023'
• GNU: date -u -d @1700000000 +'%Y-%m-%dT%H:%M:%SZ' // ISO 8601 UTC
• BSD (macOS): date -u -r 1700000000 // same result, different flag
• BSD: date -u -r 1700000000 +'%Y-%m-%dT%H:%M:%SZ'
• Both: omit -u to use TZ environment variable; export TZ=America/New_York to override
• Sub-second: date -u -d @1700000000.123 +'%Y-%m-%dT%H:%M:%S.%3NZ' (GNU only)

• man date(1) — Referenz zum Linux-Befehl date

Unix-Zeit in ein Datum in SQL umwandeln (Postgres, MySQL, SQLite, BigQuery)

Jeder große SQL-Dialekt hat eine eingebaute Funktion zur Umwandlung von Unix-Sekunden (oder Millisekunden oder Mikrosekunden) in eine native Timestamp-Spalte. Die Funktionsnamen variieren, aber die von jeder erwartete Einheit ist dokumentiert und innerhalb einer Datenbank konsistent. Verwende die dedizierte Funktion, anstatt das Ergebnis manuell mit Datumsarithmetik zu berechnen — die eingebauten Funktionen behandeln Schaltjahre, Sekundenbruchteile und Zeitzonenumrechnung korrekt.

• PostgreSQL: TO_TIMESTAMP(1700000000) // returns TIMESTAMPTZ
• PostgreSQL: TO_TIMESTAMP(unix_us / 1000000.0) // for microsecond input
• MySQL: FROM_UNIXTIME(1700000000) // returns DATETIME in session timezone
• MySQL: CONVERT_TZ(FROM_UNIXTIME(ts), @@session.time_zone, 'UTC') // force UTC
• SQLite: datetime(1700000000, 'unixepoch') // returns TEXT 'YYYY-MM-DD HH:MM:SS'
• SQLite: datetime(ms / 1000, 'unixepoch') // from milliseconds
• BigQuery: TIMESTAMP_SECONDS(1700000000), TIMESTAMP_MILLIS(ms), TIMESTAMP_MICROS(us)
• ClickHouse: toDateTime(1700000000), fromUnixTimestamp(1700000000)

• PostgreSQL — Funktionen zur Datentyp-Formatierung
• Unix-Timestamps in einer Datenbank speichern (Begleitartikel)

Unix-Zeit in ein Datum in Excel umwandeln

Excel speichert Daten als Seriennummern — die Anzahl der Tage seit dem 1.1.1900. Einen Unix-Timestamp in ein Excel-Datum umzuwandeln ist reine Einheitenumrechnung: Teile die Unix-Sekunden durch 86.400 (Sekunden pro Tag) und addiere das Datum 1.1.1970, dann formatiere die Zelle als Datum. Die Formel =A1/86400 + DATE(1970,1,1) ist die kanonische Antwort und funktioniert in jeder modernen Excel-Version. Für Millisekunden teile stattdessen durch 86.400.000. Wähle nach der Eingabe der Formel die Zelle aus, öffne Zellen formatieren (Strg+1) und wähle ein Datumsformat unter dem Reiter Zahl.

• Seconds: =A1/86400 + DATE(1970,1,1) // when A1 holds the Unix seconds value
• Milliseconds: =A1/86400000 + DATE(1970,1,1)
• Microseconds: =A1/86400000000 + DATE(1970,1,1)
• Format cell as Date after entering the formula (Ctrl+1 → Number → Date)
• Caveat: Excel's epoch is 1900-01-01, not 1970, hence the + DATE(1970,1,1) offset
• Reverse direction (date to Unix): =(A1 - DATE(1970,1,1)) * 86400

• Microsoft — DATE-Funktion

Unix-Zeit in ein Datum in Google Sheets umwandeln

Google Sheets akzeptiert dieselbe kanonische Excel-Formel und bietet zusätzlich eine dedizierte EPOCHTODATE-Funktion. Die Kurzform ist =EPOCHTODATE(A1, 1), wobei das zweite Argument der Einheitencode ist: 1 für Sekunden, 2 für Millisekunden, 3 für Mikrosekunden. Die Ausgabe ist ein an UTC verankertes Datum, das Sheets in den Spracheinstellungen der Tabelle darstellt. Dokumentiere bei Tabellen, die teamübergreifend in verschiedenen Zeitzonen geteilt werden, in der Spaltenüberschrift, welche Zeitzone die Daten darstellen sollen.

• =EPOCHTODATE(A1, 1) // seconds — shorthand
• =EPOCHTODATE(A1, 2) // milliseconds
• =EPOCHTODATE(A1, 3) // microseconds
• =A1/86400 + DATE(1970,1,1) // canonical formula — works in Sheets too
• Reverse direction: =(A1 - DATE(1970,1,1)) * 86400
• Time zone applied is the sheet's locale; check File → Settings → Time zone

UTC-Datum vs. lokales Datum — welches anzeigen

Ein Unix-Timestamp kodiert einen Zeitpunkt, keine Wanduhr-Anzeige. Zwei Besucher in verschiedenen Zeitzonen sehen denselben Unix-Timestamp als unterschiedliche Wanduhr-Daten. Das richtige Verhalten hängt davon ab, was das Datum repräsentiert: Ereignisprotokolle und Audit-Datensätze sollten in UTC angezeigt werden, um regionsübergreifend vergleichbar zu sein; nutzerbezogene Daten (Fristen, Termine, Ablaufhinweise) sollten in der lokalen Zeitzone des Nutzers angezeigt werden. Wähle immer eines und dokumentiere es; speichere niemals eine bereits in lokale Zeit umgewandelte Zeichenkette, ohne auch die Zeitzone zu speichern, aus der sie stammt.

• Server-Logs → in UTC anzeigen, die Spalte oder Diagrammachse explizit beschriften
• Nutzerbezogene Fristen → in der Zeitzone des Nutzers anzeigen (automatisch via Intl.DateTimeFormat().resolvedOptions().timeZone erkennen)
• Wiederkehrende Termine ('jeden Montag 9 Uhr Eastern') → die Zeitzone zusammen mit der Regel speichern, den nächsten Zeitpunkt bei jeder Auslösung neu berechnen
• API-Antworten → ISO 8601 mit Z-Suffix (UTC) ist der sichere Standard; die Umrechnung dem Client überlassen
• Datenbankspeicherung → immer UTC; erst in der Präsentationsschicht umrechnen

• IANA Time Zone Database (die Zeitzonenregeln, die jede Laufzeit nutzt)
• ISO 8601 — das Datumsformat für die Ausgabe

Sonderfälle: Sekundenbruchteile, negative Timestamps und das Jahr 2038

Drei Sonderfälle bringen ansonsten korrekten Code zu Fall. Mikrosekunden-Timestamps (16 Stellen) brauchen explizite Einheitenbehandlung; sie als Sekunden zu behandeln ergibt ein Datum, das 1.000.000× zu weit in der Zukunft liegt. Negative Unix-Timestamps repräsentieren Daten vor 1970 — die meisten Sprachen verarbeiten sie, aber Excel, Google Sheets und einige SQL-Funktionen kappen bei 1970 oder liefern Fehler. Das Jahr-2038-Problem ist der Überlauf der vorzeichenbehafteten 32-Bit-Ganzzahl, der am 19.1.2038 03:14:07 UTC eintritt; Werte danach erfordern BIGINT-Speicherung oder 64-Bit-time_t.

• Mikrosekunden (16 Stellen) — vor der Übergabe an Sekunden-Funktionen der Sprache durch 1.000.000 teilen
• Negative Sekunden — Daten vor 1970; JavaScript Date, Python datetime und PHP DateTime verarbeiten sie alle
• Negative Sekunden in Excel — ergeben #### oder ein falsches Datum; die Formel =A1/86400 + DATE(1970,1,1) nur für positive Werte verwenden
• Jahr 2038 — INT und vorzeichenbehaftetes 32-Bit-time_t laufen bei 2147483647 = 2038-01-19 03:14:07 UTC über
• Nach 2038 — als BIGINT speichern (vorzeichenbehaftetes 64-Bit deckt 292 Milliarden Jahre beidseits der Epoch ab)
• Vor 1900 in Excel — die Anwendung kann es nicht darstellen; in Text umwandeln oder eine vorgelagerte BCE-fähige Bibliothek verwenden

• Das Jahr-2038-Problem (Y2K38) — vollständiger Guide

Häufige Fehler beim Umwandeln von Unix-Zeit in ein Datum

Derselbe Fehler taucht jedes Mal auf, wenn jemand zum ersten Mal Unix-Zeit in ein Datum umwandelt: Das Ergebnis landet im Jahr 1970. Die Ursache ist fast immer ein vergessenes × 1000 in JavaScript oder das fehlende tz-Argument in Python oder eine von Excel automatisch gekürzte numerische Spalte. Der Begleitartikel zu Fehlern katalogisiert alle 10 — jeder einzelne tritt in Code auf, der irgendwann Unix-Zeit umwandelt. Lies ihn einmal durch, und die meisten schaffen es nie in die Produktion.

• Datum zeigt 1970 — du hast Sekunden übergeben, wo Millisekunden erwartet wurden (JS-Date-Konstruktor)
• Datum weicht um deinen lokalen UTC-Offset ab — du hast tz=timezone.utc (Python) oder die timeZone-Option (JS) vergessen
• Excel zeigt ##### oder einen #WERT!-Fehler — die Zelle ist nicht als Datum formatiert oder der Wert ist negativ
• SQL FROM_UNIXTIME liefert die falsche Wanduhrzeit — MySQL wendet @@session.time_zone an; UTC explizit erzwingen
• Server vs. Laptop liefern unterschiedliche Daten — verschiedene System-Zeitzonen; tz immer explizit übergeben

• 10 häufige Unix-Timestamp-Fehler und wie man sie behebt (Begleitartikel)