Unix-Timestamp-Konverter: Zeitstempel in Datum umrechnen

Ein Unix-Timestamp ist die Anzahl der Sekunden, die seit dem 1. Januar 1970 um 00:00 Uhr UTC vergangen sind - international auch als Epoch Time oder POSIX-Zeit bezeichnet.

Der Nullpunkt dieser Zeitrechnung heißt Unix-Epoch, und jede weitere Sekunde erhöht den Zähler um genau 1, unabhängig von Zeitzone oder Kalenderformat. Ein Beispiel zeigt das Prinzip: Der Wert 1700000000 entspricht exakt dem 14.

November 2023 um 22:13:20 Uhr UTC. Weil die Zahl selbst keine Region kennt, eignet sie sich hervorragend für Server-Logs, APIs und Datenbanken, die über mehrere Standorte hinweg denselben Zeitpunkt eindeutig speichern müssen.

Nutzen Sie den Rechner, um einen solchen Wert direkt in ein lesbares Datum zu übersetzen, statt ihn von Hand nachzurechnen.

Wichtig ist dabei nur die Unterscheidung zwischen Sekunden- und Millisekunden-Timestamps, denn beide Varianten sehen auf den ersten Blick ähnlich aus, unterscheiden sich aber um den Faktor 1000.

Ein Unix-Timestamp wird in ein Datum umgerechnet, indem Sie den Zahlenwert in das Eingabefeld eintragen und zuvor den passenden Modus wählen, also Sekunden oder Millisekunden.

Der Rechner gibt danach sofort das ISO-Datum in UTC und zusätzlich die lokale Uhrzeit für Deutschland aus.

Ein Beispiel: Der Sekundenwert 1716552000 ergibt als ISO-Datum 2024-05-24T12:00:00.000Z und als deutsche Ortszeit 24.05.2024, 14:00:00 Uhr - der Versatz von zwei Stunden ist im Mai die geltende Sommerzeit.

Prüfen Sie vor der Eingabe immer die Stellenzahl: Ein zehnstelliger Wert steht praktisch immer für Sekunden, ein dreizehnstelliger für Millisekunden.

Verwechseln Sie den Modus, weicht das angezeigte Datum nicht um Minuten, sondern typischerweise um Jahrzehnte vom erwarteten Ergebnis ab.

Für die Kontrolle eignet sich außerdem die Rückrichtung: Tragen Sie das erwartete Datum ein und vergleichen Sie den zurückgerechneten Timestamp mit Ihrem Ausgangswert.

Ob ein Timestamp in Sekunden oder Millisekunden vorliegt, erkennen Sie am zuverlässigsten an der Stellenzahl: Sekundenwerte sind 2026 zehnstellig, etwa 1735689600, während Millisekundenwerte dreizehnstellig sind, etwa 1735689600000.

Viele moderne Schnittstellen wie JavaScript mit Date.now() liefern grundsätzlich Millisekunden, klassische Unix-Werkzeuge und die meisten Datenbankfelder dagegen Sekunden.

Ein Beispiel verdeutlicht den Unterschied: Lesen Sie 1735689600 fälschlich als Millisekunden, landen Sie beim 21. Januar 1970 statt beim 1. Januar 2025 - ein Fehler von 55 Jahren durch den einen falschen Modus.

Achten Sie deshalb vor jeder Umrechnung zuerst auf die Ziffernzahl, bevor Sie einen scheinbar falschen Zeitpunkt im Backend oder Log suchen.

Nur wenn beide Systeme, die einen Timestamp austauschen, denselben Modus verwenden, bleiben Zeitdifferenzen und Sortierungen korrekt; ein Team-Protokoll zur verwendeten Einheit vermeidet solche Faktor-1000-Fehler an Systemgrenzen zuverlässig.

Das Jahr-2038-Problem ist der Überlauf eines vorzeichenbehafteten 32-Bit-Feldes, das einen Unix-Timestamp speichert, und tritt exakt am 19. Januar 2038 um 03:14:07 UTC ein.

Bis zu diesem Zeitpunkt reicht der maximale Wert 2147483647 aus; eine Sekunde später würde ein 32-Bit-System rechnerisch auf -2147483648 zurückspringen, was dem 13. Dezember 1901 entspricht.

Betroffen sind vor allem ältere Embedded-Systeme und Legacy-Datenbankspalten, die Zeitstempel noch als 32-Bit-Integer ablegen.

Moderne 64-Bit-Systeme und alle gängigen Programmiersprachen verwenden dagegen vorzeichenbehaftete 64-Bit-Integer, wodurch der nächste Überlauf erst weit jenseits des Jahres 292 Millionen liegt und praktisch keine Rolle spielt.

Prüfen Sie bei Legacy-Systemen und älterer Hardware trotzdem gezielt den verwendeten Datentyp der Zeitstempelspalte, bevor Sie sich auf Berechnungen nach 2038 verlassen.

Der Rechner selbst ist von dieser Grenze nicht betroffen und rechnet auch mit Timestamps weit nach 2038 korrekt weiter.

Aus einem Datum erzeugen Sie den passenden Unix-Timestamp, indem Sie Datum und Uhrzeit im ISO- oder lokalen Format in das entsprechende Eingabefeld eintragen; der gewählte Modus bestimmt dabei, ob die Rückgabe in Sekunden oder Millisekunden erfolgt.

Ein Beispiel: Der 1. Januar 2025 um 00:00 Uhr UTC ergibt im Sekundenmodus den Wert 1735689600. Geben Sie nur ein Tagesdatum ohne Uhrzeit ein, etwa 2026-01-01, liest der Rechner es als Mitternacht UTC und liefert 1767225600 zurück.

Diese Gegenrichtung eignet sich hervorragend, um ein geplantes Ereignis, einen Deployment-Zeitpunkt oder eine Vertragsfrist in den Timestamp umzurechnen, den ein System oder eine API erwartet.

Achten Sie darauf, dass ohne explizite Zeitzone im Eingabewert automatisch UTC angenommen wird, nicht die deutsche Ortszeit; eine lokale Uhrzeitangabe ohne Zonenkennung führt sonst zu einer Abweichung von ein bis zwei Stunden gegenüber der erwarteten UTC-Zeit.

Derselbe Unix-Timestamp zeigt in Deutschland eine andere Uhrzeit als in UTC, weil die lokale Anzeige den jeweils gültigen Zeitzonen-Offset addiert, während der gespeicherte Zahlenwert unverändert bleibt.

Im Winter gilt in Deutschland MEZ mit UTC+1, im Sommer MESZ mit UTC+2 - ein Unterschied, den die IANA-Zeitzonendatenbank für Europe/Berlin exakt hinterlegt.

Ein Beispiel: Der Timestamp 1782000000 ergibt in UTC 2026-06-21T00:00:00Z, lokal in Berlin aber 21.06.2026, 02:00:00 Uhr, weil im Juni die Sommerzeit mit zwei Stunden Versatz gilt.

Vergleichen Sie deshalb niemals eine UTC-Ausgabe direkt mit einer lokalen Systemzeit, ohne die Zeitzone zu berücksichtigen, sonst wirkt ein technisch korrekter Wert wie ein Fehler.

Besonders in der Nacht der Zeitumstellung Ende März und Ende Oktober lohnt ein zweiter Blick, denn dort wiederholt oder überspringt die lokale Uhrzeit eine Stunde, während der Unix-Timestamp selbst lückenlos weiterzählt.

Unix-Timestamps rechnen Sie in MySQL mit der Funktion FROM_UNIXTIME(timestamp) in ein lesbares DATETIME um; beachten Sie dabei, dass die klassische TIMESTAMP-Spalte an dieselbe 32-Bit-Grenze bis 2038 gebunden ist wie der Unix-Timestamp selbst.

In Python liefert time.time() den aktuellen Wert in Sekunden, während datetime.fromtimestamp(ts) daraus ein lesbares Datumsobjekt macht.

JavaScript arbeitet dagegen grundsätzlich in Millisekunden: new Date(timestamp * 1000).toISOString() wandelt einen Sekundenwert korrekt in eine ISO-8601-Zeichenkette um, der Faktor 1000 gleicht die Einheit an.

Achten Sie bei jeder Sprache zuerst auf die erwartete Einheit, denn ein Python-Sekundenwert direkt in eine JavaScript-Millisekundenfunktion eingesetzt landet um den Faktor 1000 daneben.

Der Rechner hilft, ein Ergebnis aus beliebigem Code schnell gegenzuprüfen, ohne selbst ein Skript oder eine Konsole zu öffnen; tragen Sie dazu einfach den Rückgabewert Ihrer Funktion ein und vergleichen Sie ihn mit der angezeigten Umrechnung.

Der aktuelle Unix-Timestamp ist die Zahl der Sekunden, die seit dem 1. Januar 1970 um 00:00 Uhr UTC bis jetzt vergangen sind, und wächst jede Sekunde um genau 1. Zum Stichtag 26.

September 2026, 00:00 Uhr UTC, entspricht das dem Wert 1790380800 in Sekunden beziehungsweise 1790380800000 in Millisekunden.

Um den aktuellen Wert abzulesen, tragen Sie das heutige Datum samt Uhrzeit in das Datumsfeld ein und lesen den zugehörigen Unix-Wert direkt aus dem Ergebnis Timestamp aus Datum ab.

Nutzen Sie diese Richtung zum Beispiel, um ein Sitzungs-Ablaufdatum oder einen geplanten Cron-Lauf gegen den aktuellen Zeitpunkt zu prüfen.

Beachten Sie, dass ein einmal abgelesener Wert nur für den exakten Moment der Eingabe gilt und nicht automatisch weiterläuft; für einen live mitlaufenden Zähler bräuchten Sie stattdessen eine serverseitige Uhr oder ein eigenes Skript.

Windows, Excel und SAP speichern Zeitstempel anders als Unix-Systeme, weil jede Plattform einen eigenen Nullpunkt und eine eigene Zähleinheit für ihre interne Zeitrechnung festgelegt hat.

Windows-Systemzeit (FILETIME) zählt beispielsweise 100-Nanosekunden-Intervalle seit dem 1. Januar 1601, während Excel Datumswerte als fortlaufende Tageszahl seit dem 30. Dezember 1899 ablegt.

Ein Datenbankfeld aus SAP oder einer Automatisierungsplattform wie IoBroker kann daher denselben realen Zeitpunkt als völlig andere Zahl zeigen als ein Unix-Timestamp, obwohl beide korrekt sind.

Vergleichen Sie zwei Zeitstempel aus unterschiedlichen Systemen deshalb nie direkt als Zahl, sondern rechnen Sie beide zuerst in ein gemeinsames Format wie ISO 8601 um.

Der Timestamp-Konverter deckt gezielt die Unix-Basis in Sekunden und Millisekunden ab; für Windows-FILETIME oder das Excel-Nulldatum ist vorher eine zusätzliche Umrechnung auf die Unix-Epoch nötig, bevor Sie den Wert hier eintragen können.

Ja, ein Unix-Timestamp ist als reine Zahl grundsätzlich zeitzonenneutral und bezieht sich intern immer auf UTC, auch wenn er lokal in einer anderen Zeitzone angezeigt wird. Der Wert beschreibt lediglich den Sekundenabstand zum Epoch-Nullpunkt vom 1.

Januar 1970 und kennt selbst weder Region noch Sommerzeit.

Genau deshalb eignet sich das Format für verteilte Systeme: Server in Frankfurt, Dublin oder Singapur speichern denselben eindeutigen Wert, ohne sich zuvor auf eine gemeinsame lokale Zeit einigen zu müssen.

Beachten Sie außerdem, dass Unix-Zeit keine Schaltsekunden abbildet, sondern jeden Tag pauschal mit genau 86400 Sekunden rechnet; tatsächlich eingefügte Schaltsekunden werden dabei schlicht übersprungen.

Für die Genauigkeitsanforderungen von Web-APIs, Logging-Systemen und den meisten Datenbanken ist diese Vereinfachung völlig ausreichend.

Prüfen Sie nur bei hochpräzisen wissenschaftlichen Anwendungen, ob eine spezielle Zeitskala wie TAI statt der vereinfachten Unix-Zeit nötig ist.