Unix-Timestamp

Wie rechnet der timestamp converter Unix-Zeit in ein Datum um?

Ein Unix-Timestamp zählt die Zeit ohne Schaltsekunden seit 1970-01-01T00:00:00.000Z. Das Z steht für UTC. Der Wert beschreibt also einen festen Zeitpunkt, unabhängig davon, ob du ihn in Berlin, London, New York oder Tokio anzeigen lässt.

Die Rechnung ist bei Sekunden und Millisekunden unterschiedlich zu lesen: Unix-Sekunden = Millisekunden seit 1970-01-01T00:00:00Z ÷ 1000. Wenn ein System Millisekunden liefert, wird zuerst durch 1000 geteilt. Wenn ein System bereits Unix-Sekunden liefert, kann der Wert direkt als Sekunden seit dem Startzeitpunkt interpretiert werden.

Beispiel: Der Timestamp 1.779.297.811 als Sekundenwert ergibt in UTC 2026-05-20T17:23:31.000Z. In der Zeitzone Europe/Berlin wird derselbe Zeitpunkt als Mittwoch, 20. Mai 2026 um 19:23:31 MESZ angezeigt. Der UTC-Offset an diesem Zeitpunkt ist GMT+02:00.

Wichtig ist: Der Timestamp selbst ändert sich durch die Zeitzone nicht. Nur die lokale Darstellung ändert sich. Deshalb ist 2026-05-20T17:23:31.000Z in UTC derselbe Moment wie Mittwoch, 20. Mai 2026 um 19:23:31 MESZ in Berlin.

Timestamp in Datum: Sekunden oder Millisekunden erkennen

Ein häufiger Fehler beim Umrechnen ist die falsche Einheit. Viele APIs liefern Unix-Zeit in Sekunden, JavaScript arbeitet intern mit Millisekunden. Der Zahlenwert kann dadurch ähnlich aussehen, aber ein völlig anderes Datum ergeben.

Nimm 1.779.297.811 als Beispiel. Wenn du den Wert als Sekunden eingibst, erhältst du 2026-05-20T17:23:31.000Z. In Berlin ist das Mittwoch, 20. Mai 2026 um 19:23:31 MESZ.

Wenn du denselben Wert als Millisekunden behandelst, ist das Ergebnis dagegen 1970-01-21T14:14:57.811Z. Als Unix-Sekunden sind das 1.779.297,811, nicht 1.779.297.811,000.

Daran siehst du den Unterschied gut: Sekundenwerte führen bei typischen aktuellen Datumsangaben zu großen Timestamp-Zahlen ohne Millisekundenanteil. Millisekundenwerte sind für denselben Zeitpunkt deutlich länger. Wenn dein Ergebnis plötzlich nahe am Beginn der Unix-Zeit liegt, obwohl du ein modernes Datum erwartest, ist fast immer die Einheit falsch gewählt.

Warum zeigt Unix-Zeit je nach Zeitzone eine andere Uhrzeit?

Unix-Zeit ist nicht „deutsche Zeit“ oder „New Yorker Zeit“. Sie beschreibt einen Zeitpunkt auf der UTC-Zeitachse. Die lokale Uhrzeit entsteht erst bei der Anzeige in einer Zeitzone.

Ein gutes Beispiel ist 1.700.000.000 Unix-Sekunden. In UTC ist das 2023-11-14T22:13:20.000Z, angezeigt als Dienstag, 14. November 2023 um 22:13:20 UTC. In Europe/Berlin ist es derselbe Zeitpunkt, aber die lokale Ausgabe lautet Dienstag, 14. November 2023 um 23:13:20 MEZ. Der Offset ist dort GMT+01:00.

Auch andere Zeitzonen verschieben nur die Anzeige. 1.600.000.000 Unix-Sekunden ergibt in America/New_York Sonntag, 13. September 2020 um 08:26:40 GMT-4, während der UTC-Wert 2020-09-13T12:26:40.000Z lautet. In Europe/London ergibt 1.000.000.000 Unix-Sekunden Sonntag, 9. September 2001 um 02:46:40 GMT+1, obwohl die UTC-Zeit 2001-09-09T01:46:40.000Z ist.

Für Logs, Datenbanken und Schnittstellen ist deshalb UTC meist die stabilere Schreibweise. Für Nutzeroberflächen ist die lokale Zeit verständlicher. Beides kann korrekt sein, solange klar ist, welche Zeitzone verwendet wurde.

Datum in Unix-Timestamp umrechnen: ISO-Zeit, Offset und Europe/Berlin

Bei der Rückrichtung gibst du ein Datum mit Uhrzeit ein und erhältst den passenden Unix-Timestamp. Entscheidend ist, ob die Eingabe schon einen Offset enthält. Ein Z bedeutet UTC. Ein Offset wie +02:00 oder +01:00 legt die Abweichung von UTC ausdrücklich fest. Ohne solchen Zusatz wird die gewählte Zeitzone für die Interpretation genutzt.

Beispiele:

• 2024-01-01T00:00:00Z ergibt 1.704.067.200,000 Unix-Sekunden und 1.704.067.200.000 Unix-Millisekunden.
• 2026-05-20T17:23:31+02:00 in Europe/Berlin ergibt 1.779.290.611,000 Unix-Sekunden. Die UTC-Zeit dazu ist 2026-05-20T15:23:31.000Z.
• 2024-02-29T12:00:00+01:00 in Europe/Berlin ergibt 1.709.204.400,000 Unix-Sekunden. Die UTC-Zeit ist 2024-02-29T11:00:00.000Z.
• 2025-07-01T09:30:00+09:00 in Asia/Tokyo ergibt 1.751.329.800,000 Unix-Sekunden.

Wenn du eine lokale Uhrzeit aus Deutschland in Unix-Zeit umrechnest, achte besonders auf den Offset. Im Beispiel 2026-05-20T17:23:31+02:00 ist die lokale Berliner Uhrzeit ausdrücklich mit GMT+02:00 gemeint. Ohne den Offset muss die Zeitzone richtig gewählt sein, sonst wird aus derselben geschriebenen Uhrzeit ein anderer Zeitpunkt.

Typische Fehler beim Unix-Timestamp umrechnen

Die meisten falschen Ergebnisse entstehen durch uneindeutige Eingaben. Eine übersprungene lokale Uhrzeit während der Frühlingsumstellung wird abgewiesen. Historische und künftige Zonenregeln stammen aus den Zeitzonendaten deines Browsers. Diese Punkte helfen dir beim Prüfen:

• Sekunden und Millisekunden nicht verwechseln: 1.779.297.811 als Sekunden führt zu 2026-05-20T17:23:31.000Z; als Millisekunden zu 1970-01-21T14:14:57.811Z.
• UTC nicht mit lokaler Zeit gleichsetzen: 1.700.000.000 ist in UTC Dienstag, 14. November 2023 um 22:13:20 UTC, in Berlin aber Dienstag, 14. November 2023 um 23:13:20 MEZ.
• Offset in der Eingabe beachten: Bei 2026-05-20T17:23:31+02:00 hat +02:00 Vorrang. Die UTC-Zeit ist dann 2026-05-20T15:23:31.000Z.
• Doppelte Herbst-Uhrzeit klären: In Berlin kann eine lokale Uhrzeit bei der Zeitumstellung doppelt vorkommen. Für 2026-10-25 02:30:00 mit späterem Zeitpunkt ist das Ergebnis 1.792.891.800,000 Unix-Sekunden und die UTC-Zeit 2026-10-25T01:30:00.000Z.
• Ausgabeformat sauber trennen: ISO-UTC wie 2026-05-20T17:23:31.000Z ist gut für Technik. Eine Ausgabe wie Mittwoch, 20. Mai 2026 um 19:23:31 MESZ ist gut für Menschen.

Praktisch ist ein kurzer Gegencheck mit bekannten Referenzwerten. 0 entspricht 1970-01-01T00:00:00.000Z. 946.684.800 entspricht 2000-01-01T00:00:00.000Z. 2.147.483.647 entspricht 2038-01-19T03:14:07.000Z.