Unix-Timestamp-Konverter: Zeitstempel in Datum umwandeln

Ein Unix-Timestamp wird umgerechnet, indem Sie den Zahlenwert in das Eingabefeld eintragen und vorher korrekt zwischen Sekunden und Millisekunden wählen; der Rechner gibt daraufhin Datum und Uhrzeit für die gewählte Zeitzone aus und zeigt zusätzlich die Rückrechnung vom Datum zurück zur Zahl.

Ein konkretes Beispiel verdeutlicht das: Der Wert 1700000000 entspricht in Sekunden dem 14. November 2023 um 22:13:20 Uhr UTC, während dieselben Ziffern als Millisekunden interpretiert auf das Jahr 1970 fallen würden.

Genau dadurch werden Einheitenfehler in Logs und API-Antworten sofort sichtbar, statt sich erst spät in der Auswertung zu zeigen.

Achten Sie auf die Stellenzahl der Eingabe, damit ein Faktor-1000-Fehler zwischen Sekunden und Millisekunden nicht unbemerkt bleibt und das Ergebnis nicht um Jahrzehnte daneben liegt.

Den gleichen Wert können Sie direkt in der Browser-Konsole über new Date(1700000000 * 1000) überprüfen, was den UTC-Zeitpunkt als ISO-8601-Zeichenkette zurückgibt.

Diese Methode ergänzt den Rechner ideal, wenn Sie API-Antworten mit Unix-Zeitstempeln rasch ohne eigenes Skript verifizieren möchten.

Die Zeitbasis eines Unix-Timestamps ist die Anzahl der Sekunden seit dem 1. Januar 1970 um 00:00:00 Uhr in UTC, dem sogenannten Epoch-Nullpunkt, und genau deshalb eignet sich das Format hervorragend für systemübergreifende Zeitwerte.

Manche Systeme zählen stattdessen in Millisekunden, etwa die meisten JavaScript-Schnittstellen, sodass dieselbe Sekunde dort als tausendfach größere Zahl erscheint.

Die Zahl selbst ist zeitzonenneutral, weil sie nur einen festen Abstand zum Epoch-Punkt beschreibt und keine Region kennt. Ein klassischer Stolperstein ist das Jahr-2038-Problem: Bei einer vorzeichenbehafteten 32-Bit-Speicherung läuft der Wert am 19.

Januar 2038 über. Achten Sie bei der Interpretation immer auf die gewählte Einheit und Bitbreite, damit Werte aus verschiedenen Quellen konsistent in lesbare Zeiten zurückgeführt werden.

Moderne 64-Bit-Systeme und alle gängigen Programmiersprachen verwenden vorzeichenbehaftete 64-Bit-Integer für Unix-Timestamps, womit das Jahr-2038-Problem praktisch gelöst ist: Der maximale darstellbare Wert liegt weit jenseits des Jahres 292 Millionen.

Beim Arbeiten mit Legacy-Datenbanken lohnt dennoch ein Blick auf den verwendeten Datentyp für Zeitstempelspalten.

Die angezeigte Zeit unterscheidet sich zwischen Zeitzonen erst bei der Darstellung, weil derselbe gespeicherte Timestamp lokal mit unterschiedlichen Offset- und Sommerzeitregeln ausgegeben wird.

Der zugrunde liegende Zahlenwert bleibt dabei vollkommen identisch und ändert sich nicht.

Ein Beispiel: Ein UTC-Wert von 12:00 Uhr erscheint in Deutschland im Winter als 13:00 Uhr (Offset plus eine Stunde) und in New York als 07:00 Uhr (Offset minus fünf Stunden).

Im Sommer verschiebt die Sommerzeit diese Offsets jeweils um eine weitere Stunde, was häufig zu Fehlinterpretationen führt.

Achten Sie deshalb stets auf die aktiv gewählte Zone im Ergebnisfeld, damit Sie die zeitzonenneutrale UTC-Logik des Timestamps nicht versehentlich mit der lokalen Anzeigezeit verwechseln und falsche Schlüsse aus Logs ziehen.

Besonders kritisch sind die Umstellungsnächte selbst: Beim Wechsel von CEST auf CET wiederholen sich manche Ortszeiten einmalig, sodass ein Timestamp in dieser Stunde eindeutig bleibt, während eine lokale Zeitangabe allein mehrdeutig wäre.

ISO-8601-Ausgaben mit explizitem Offset wie 2026-10-25T02:30:00+02:00 vermeiden genau diese Verwechslung beim Austausch zwischen Systemen.

Timestamp-Werte liegen entweder in Sekunden oder in Millisekunden vor, und die Stellenzahl ist dabei meist der schnellste Indikator zur Unterscheidung.

Ein aktueller Sekunden-Timestamp ist derzeit 10-stellig (etwa 1700000000), während der entsprechende Millisekunden-Wert 13-stellig ist (etwa 1700000000000).

Viele moderne Programmierschnittstellen, allen voran JavaScript mit Date.now, liefern grundsätzlich Millisekunden, klassische Unix-Werkzeuge dagegen Sekunden.

Wer die Einheit verwechselt, landet schnell um den Faktor 1000 daneben: Ein Sekundenwert fälschlich als Millisekunden gelesen rutscht von 2023 zurück ins Jahr 1970.

Achten Sie daher konsequent auf diese Unterscheidung vor jeder Umrechnung und prüfen Sie im Zweifel die Stellenzahl, damit Datum und Uhrzeit nicht um Jahrzehnte falsch angezeigt werden und Auswertungen verlässlich bleiben.

In Python gibt time.time() Sekunden zurück, während JavaScript mit Date.now() Millisekunden liefert; ein schriftlich festgelegtes Team-Protokoll zum verwendeten Maßstab vermeidet fehlerträchtige Konvertierungen an Systemgrenzen.

Der Rechner zeigt beide Einheiten parallel an, damit Sie sofort den richtigen Wert in Ihre Codezeile übernehmen können.

Entwickler nutzen den Rechner, um API-Zeitstempel zu prüfen, einzelne Log-Einträge zeitlich zuzuordnen oder Werte aus verschiedenen Zeitzonen miteinander zu vergleichen.

Geben Sie einfach einen Timestamp oder ein Datum ein und erhalten Sie die Umrechnung in beide Richtungen ohne eigenes Skript.

In der Praxis hilft das etwa, wenn ein JSON-Payload ein Feld wie createdAt mit dem Wert 1700000000 enthält und Sie sofort wissen wollen, welcher reale Zeitpunkt gemeint ist.

Auch beim Debuggen von Token-Ablaufzeiten, etwa dem Feld exp in einem JWT, lässt sich so in Sekunden klären, ob ein Zugriff bereits abgelaufen ist.

So validieren Sie Payloads, Cron-Zeiten und Debug-Ausgaben in Sekunden und vermeiden Rechenfehler, die sich sonst durch die gesamte Auswertungskette ziehen würden.

Im Shell-Kontext liefert date +%s auf Linux und macOS den aktuellen Epoch-Wert in Sekunden; date -d @1700000000 rechnet ihn zurück in eine lesbare Ortszeit.

Für JavaScript steht zusätzlich new Date(timestamp * 1000).toISOString() bereit, um einen Sekunden-Timestamp direkt in eine ISO-8601-Zeichenkette umzuwandeln.

Ja, der Unix-Timestamp ist grundsätzlich auf UTC bezogen und damit als reine Zahl zeitzonenneutral gespeichert; lokal wird daraus nur die Darstellung abgeleitet. Die Zahl beschreibt schlicht den Sekundenabstand zum Epoch-Punkt vom 1.

Januar 1970 und kennt selbst keine Region und keine Sommerzeit. Missverständnisse entstehen daher fast immer erst bei der Anzeige in verschiedenen Ländern, wenn dieselbe Zahl etwa in Berlin und in Tokio sehr unterschiedliche Ortszeiten ergibt.

Genau deshalb ist das Format für verteilte Systeme so praktisch: Server in mehreren Rechenzentren speichern denselben eindeutigen Wert, ohne sich auf eine gemeinsame lokale Zeit einigen zu müssen.

Achten Sie konsequent auf die Trennung zwischen Speicherformat in UTC und gewählter Ausgabe-Zeitzone, damit Analysen und Zeitvergleiche über Standorte hinweg konsistent bleiben.

Beachten Sie außerdem, dass Unix-Zeit keine Schaltsekunden abbildet: Jeder Tag enthält rechnerisch exakt 86400 Sekunden, tatsächlich eingefügte Schaltsekunden werden schlicht übersprungen.

Für die Genauigkeitsanforderungen typischer Web-APIs und Logging-Systeme ist diese Vereinfachung vollkommen ausreichend und erleichtert die systemübergreifende Berechnung von Zeitdifferenzen.

Einen Unix-Timestamp wählen Sie überall dort, wo Maschinen Zeit speichern, vergleichen oder berechnen sollen, denn als einzelne Zahl in Sekunden oder Millisekunden lässt er sich kompakt ablegen und mit einfacher Subtraktion in eine Dauer umrechnen.

Das ISO-8601-Format wie 2026-03-14T12:00:00Z nutzen Sie hingegen dort, wo Menschen mitlesen oder Zeitzoneninformation direkt erkennbar sein soll, etwa in Log-Dateien, Konfigurationen oder Schnittstellen-Dokumentationen.

Ein Timestamp ist platzsparend und rechenfreundlich, aber für das Auge nichtssagend; ISO 8601 ist sofort lesbar, dafür länger und aufwendiger zu parsen.

Der Rechner wandelt beide Richtungen verlustfrei ineinander um, sodass Sie intern mit Timestamps arbeiten und nur an den menschlichen Berührungspunkten auf das lesbare ISO-Format wechseln können, ohne die Genauigkeit zu verlieren.

In relationalen Datenbanken empfiehlt sich ein BIGINT-Spaltentyp für Unix-Timestamps in Millisekunden, da er zeitzonenfrei sortierbar ist und sich ohne Konvertierung an JavaScript-APIs übergeben lässt.

ISO-8601-Felder wie TIMESTAMPTZ bieten zwar direkte Lesbarkeit, erfordern aber eine explizite Zeitzonen-Konvertierung bei jedem Datenaustausch mit Frontend-Code.

Ein Unix-Timestamp wird für Deutschland korrekt umgerechnet, wenn Sie im Rechner explizit die Zeitzone Europe/Berlin auswählen und damit die geltenden CET- und CEST-Regeln auf die Ausgabe anwenden.

Im Winter gilt dabei CET mit einem Offset von UTC plus einer Stunde, im Sommer CEST mit UTC plus zwei Stunden. Konkret bedeutet das: Ein UTC-Wert von 12:00 Uhr erscheint in Berlin im Januar als 13:00 Uhr und im Juli als 14:00 Uhr.

Umgekehrt lässt sich aus einer lokalen Berliner Zeit der passende Timestamp erzeugen, sofern Sie dieselbe Zone konsequent wählen.

Achten Sie auf die eingestellte Zeitzone sowohl im Eingabe- als auch im Ausgabeweg, damit der Sommerzeitwechsel Ende März und Ende Oktober korrekt berücksichtigt wird und keine Stunde verloren geht oder doppelt zählt.

Die Notation UTC+1 und UTC+2 sind vereinfacht; tatsächlich entscheidet die IANA-Zeitzonendatenbank hinter Europe/Berlin, welcher Offset zu welchem Datum gilt, da historische Regeländerungen dort vollständig hinterlegt sind.

Der Rechner nutzt diese Datenbank intern, damit auch Timestamps aus den 1970er-Jahren für Deutschland korrekt ausgewertet werden.