Start›Technik & Text›Unix-Timestamp-Rechner

Unix-Timestamp-Rechner

Sekunden seit 1970 in Datum und Uhrzeit, und Datum in Timestamp, Ortszeit und UTC.

Welches Datum ist dieser Timestamp?

Sekunden oder Millisekunden.

Beispiel: 1700000000 ist der 14.11.2023, 22:13:20 UTC

Welcher Timestamp ist dieses Datum?

Datum und Uhrzeit in Ortszeit.

Beispiel: 1. Januar 2030, 0:00 Uhr (in Deutschland: 1893452400)

Anzeige

300 × 250

So funktioniert der Unix-Timestamp-Rechner

Der Unix-Timestamp-Rechner rechnet in beide Richtungen: Der erste Kasten macht aus einem Timestamp, der Zahl der Sekunden seit dem 1. Januar 1970, Datum und Uhrzeit in Ihrer Ortszeit und in UTC, mit Wochentag, ISO-8601-Schreibweise und dem Abstand zu jetzt; Werte über 100 Milliarden liest er als Millisekunden, wie JavaScript und Java sie liefern. Der zweite Kasten macht aus Datum und Uhrzeit in Ortszeit den Unix-Timestamp in Sekunden und Millisekunden, hexadezimal und als Tage seit 1970. Das ist das Werkzeug für Logdateien, Datenbanken, APIs und die Frage, was die Zahl in der Fehlermeldung bedeutet.

Merksatz: Die Unix-Zeit zählt Sekunden seit Mitternacht UTC am 1. Januar 1970, ohne Zeitzonen und ohne Sommerzeit, und erst die Anzeige macht daraus Ortszeit. Die Eselsbrücke: Eine Milliarde war der 9. September 2001, zwei Milliarden werden der 18. Mai 2033, und 86.400 Sekunden sind ein Tag.

Drei Beispiele:

  • 1700000000: 14. November 2023, 22:13:20 UTC, in Deutschland 23:13:20, ein Dienstag.
  • 2147483647: 19. Januar 2038, 03:14:07 UTC, der größte Wert eines 32-Bit-Zählers, das Jahr-2038-Problem; Timestamp 0 ist der 1. Januar 1970, 00:00 UTC, in Deutschland 1 Uhr.
  • 1. Januar 2030, 0:00 Uhr deutscher Zeit: Timestamp 1893452400, das ist der 31. Dezember 2029, 23:00 UTC, hexadezimal 70dbca70, 21.915 Tage seit 1970.

Formeln: Timestamp = Sekunden seit 1970-01-01 00:00:00 UTC, Millisekunden = Timestamp × 1.000, Tage seit 1970 = Timestamp / 86.400, Ortszeit = UTC + Zeitzonenversatz (Deutschland +1, Sommer +2). Die Tage zwischen zwei Daten rechnet der Tage-Rechner, und die Uhrzeit in anderen Zeitzonen der Zeitzonen-Rechner.

Wissenswertes zum Thema

Was die Unix-Zeit ist und warum sie keine Zeitzone kennt

Die Unix-Zeit, auch Epoch Time oder POSIX-Zeit, ist eine einzige Zahl: die Sekunden, die seit dem 1. Januar 1970, 00:00:00 UTC, der Unix-Epoche, vergangen sind, 1700000000 am 14. November 2023 um 22:13:20 UTC, und sie ist deshalb das Zeitformat fast aller Computer, Datenbanken, Dateisysteme und Netzprotokolle, weil sich mit einer Zahl rechnen lässt, Differenz, Sortierung, Vergleich, ohne Monate mit 28 bis 31 Tagen, Schaltjahre und Zeitzonen. Die Zeitzone kommt erst bei der Anzeige dazu: Derselbe Timestamp ist in Berlin 23:13:20, in London 22:13:20, in New York 17:13:20, und der Rechner zeigt Ortszeit nach der Zeitzone des Browsers und UTC daneben; wer einen Timestamp aus einem Server in den USA liest, bekommt denselben Wert und muss nur wissen, dass die Ortszeit dort anders ist. Schaltsekunden, die seit 1972 27-mal eingefügt wurden, ignoriert die Unix-Zeit, jeder Tag hat 86.400 Sekunden, und die Uhr wird bei einer Schaltsekunde angehalten oder verschmiert, so dass Timestamps nie zweimal dieselbe Sekunde zählen, aber die Unix-Zeit um 27 Sekunden von der Atomzeit abweicht. Negative Werte sind Zeiten vor 1970, minus 86.400 ist der 31. Dezember 1969, und viele Systeme verweigern sie. Millisekunden-Timestamps haben 13 Stellen statt 10, 1700000000000, und stammen aus JavaScript, Java und vielen APIs, der Rechner erkennt sie an der Größe. Für die Umrechnung zwischen Zeitzonen mit Sommerzeit und Datumsgrenze gibt es den Zeitzonen-Rechner.

Timestamps in der Praxis: Logs, Datenbanken, APIs, Dateien

In Logdateien stehen Timestamps, weil sie sortierbar und kompakt sind, und die Fehlersuche beginnt mit der Umrechnung: "error at 1700000000" ist der 14. November 2023, 23:13 deutscher Zeit, und der Abstand zu jetzt, den der Rechner in Tagen zeigt, sagt, ob der Eintrag frisch ist. Datenbanken speichern Zeiten als Timestamp oder als DATETIME, MySQL hat beides, und der Unterschied ist die Zeitzone, TIMESTAMP wird in UTC gespeichert und bei der Abfrage umgerechnet, DATETIME nicht, was bei Serverumzügen die Uhrzeiten verschiebt; die Regel "in UTC speichern, bei der Anzeige umrechnen" ist deshalb die wichtigste im Umgang mit Zeit. APIs liefern Timestamps als Zahl oder als ISO-8601-Text, 2023-11-14T22:13:20Z, mit dem Z für UTC oder einem Versatz wie +01:00, und der Rechner zeigt beide Formen. JSON Web Tokens haben Ablaufzeiten als Timestamp im Feld "exp", Cookies ein Verfallsdatum, Zertifikate "not after", und Cache-Header rechnen mit Sekunden; wer einen Fehler "token expired" sieht, prüft mit dem Rechner, wann genau. Dateisysteme speichern Erstellungs- und Änderungszeiten als Timestamp, Windows allerdings seit 1601 in 100-Nanosekunden-Schritten, und Excel zählt Tage seit 1900 als Dezimalzahl, so dass die Umrechnung in Excel "= Timestamp / 86400 + 25569" lautet, das Datum formatiert. In Programmiersprachen liefert time() in PHP, Date.now() in JavaScript, time.time() in Python und System.currentTimeMillis() in Java den aktuellen Wert, den der Rechner als "Jetzt" mit anzeigt. Für Berechnungen mit Kalenderdaten, Werktage, Fristen, Alter, nimmt man besser den Datumsrechner, der Monate und Schaltjahre kennt.

Das Jahr-2038-Problem und andere Fallen

Ein 32-Bit-Zähler mit Vorzeichen endet bei 2.147.483.647, und das ist der 19. Januar 2038, 03:14:07 UTC; eine Sekunde später springt er auf minus 2.147.483.648, den 13. Dezember 1901, und Systeme, die noch 32-Bit-Zeit nutzen, rechnen dann mit falschem Datum. Linux-Kernel, Datenbanken und moderne Sprachen sind längst auf 64 Bit umgestellt, mit dem Ende im Jahr 292 Milliarden, aber eingebettete Systeme, Router, Steuerungen, alte Dateiformate und Datenbanken mit INT-Spalten für Timestamps haben das Problem, MySQLs TIMESTAMP-Typ endete bis Version 8.0.28 bei 2038, und die ersten Ausfälle gab es schon, als Software 20-Jahres-Fristen über 2038 hinaus rechnete. Die zweite Falle ist die Einheit, Sekunden gegen Millisekunden, eine Zahl mit 13 Stellen in ein Feld für 10 Stellen ergibt ein Datum im Jahr 55.000, und der Rechner liest ab 100 Milliarden als Millisekunden. Die dritte ist die Zeitzone beim Eingeben: Der zweite Kasten nimmt das Datum als Ortszeit des Browsers, 1. Januar 2030 0:00 in Berlin ist 1893452400, in UTC wäre es 1893456000, 3.600 mehr, und Mitternacht ist nie eindeutig ohne Zone. Die vierte ist die Sommerzeit, die beim Übergang eine Stunde doppelt oder gar nicht existieren lässt, 2:30 Uhr am letzten Sonntag im März gibt es in Deutschland nicht. Die fünfte ist die Annahme, ein Tag habe immer 86.400 Sekunden in Ortszeit, am Umstellungstag sind es 82.800 oder 90.000. Die sechste sind die Kalender vor 1582, die Unix-Zeit rechnet gregorianisch rückwärts, als hätte es die Reform immer gegeben. Welcher Wochentag ein beliebiges Datum war, bestätigt der Wochentag-Rechner, der Timestamp-Rechner zeigt ihn mit.

Ein Stück Geschichte: Warum ausgerechnet 1970

Die Unix-Zeit begann nicht 1970, sondern 1971: Die erste Ausgabe des Unix-Handbuchs vom November 1971 definierte die Zeit als Sechzigstelsekunden seit dem 1. Januar 1971, und weil ein 32-Bit-Zähler damit nach 829 Tagen überlief, änderten Ken Thompson und Dennis Ritchie an den Bell Labs die Einheit auf Sekunden und schoben den Nullpunkt der Einfachheit halber auf den 1. Januar 1970, "ohne tiefere Bedeutung", wie Ritchie später sagte, ein rundes Datum nahe am Beginn von Unix. Der POSIX-Standard schrieb die Definition 1988 fest, ohne Schaltsekunden, was die Diskussion bis heute beschäftigt. Am 9. September 2001 um 01:46:40 UTC erreichte die Unix-Zeit eine Milliarde, gefeiert von Programmierern in Kopenhagen, am 13. Februar 2009 um 23:31:30 UTC den Wert 1234567890, und am 14. November 2023 die 1,7 Milliarden, die der Rechner als Beispiel nutzt. Das Jahr-2038-Problem wurde 1996 in Newsgroups diskutiert, der Linux-Kernel stellte 2020 mit Version 5.6 die letzten 32-Bit-Schnittstellen um, und OpenBSD schon 2014. Windows hat seine eigene Epoche, den 1. Januar 1601, der Beginn des 400-Jahres-Zyklus des gregorianischen Kalenders, Excel den 1. Januar 1900 mit einem absichtlich beibehaltenen Fehler, der 1900 als Schaltjahr zählt, GPS den 6. Januar 1980 in Wochen, und Apples Cocoa den 1. Januar 2001; die Unix-Zeit hat sie alle überlebt, weil sie die einfachste ist. Der Rechner rechnet die Zahl, die Thompson und Ritchie 1971 auf 1970 zurücklegten.

Praktische Tipps

Speichern Sie Zeiten in UTC als Timestamp und rechnen Sie erst bei der Anzeige in Ortszeit um. Zählen Sie die Stellen, 10 sind Sekunden, 13 Millisekunden. Prüfen Sie bei Fristen und Zertifikaten das Ablaufdatum mit dem Rechner, bevor Sie suchen. Nutzen Sie ISO 8601 mit Z oder Versatz für Textformate. Vermeiden Sie 32-Bit-Felder für Timestamps, auch in Datenbanken. Testen Sie Software mit Daten nach dem 19. Januar 2038. Rechnen Sie Kalenderfristen mit dem Datumsrechner, nicht mit 86.400 mal Tage. Und merken Sie sich, dass Mitternacht ohne Zeitzone keine Uhrzeit ist. Die Tage zwischen zwei Timestamps liefert der Tage-Rechner mit Wochen und Werktagen.

Häufige Fragen

Was ist ein Unix-Timestamp?

Die Zahl der Sekunden seit dem 1. Januar 1970, 00:00:00 UTC, ohne Zeitzone und Sommerzeit. 1700000000 ist der 14. November 2023, 22:13:20 UTC, in Deutschland 23:13:20. Computer, Datenbanken und APIs nutzen das Format, weil sich mit einer Zahl rechnen und sortieren lässt.

Wie rechne ich einen Timestamp in ein Datum um?

Den Wert in den ersten Kasten eintragen, der Rechner zeigt Ortszeit, UTC, Wochentag und ISO 8601. Der Wert 2147483647 ist der 19. Januar 2038, 03:14:07 UTC, Timestamp 0 der 1. Januar 1970, 00:00 UTC. Von Hand: durch 86.400 teilen ergibt Tage seit 1970, der Rest die Uhrzeit.

Wie rechne ich ein Datum in einen Timestamp um?

Datum und Uhrzeit in Ortszeit in den zweiten Kasten: Der 1. Januar 2030, 0:00 Uhr deutscher Zeit ist 1893452400, das sind 21.915 Tage seit 1970. In UTC wäre dieselbe Uhrzeit 1893456000, eine Stunde später, weil Deutschland im Winter UTC+1 hat.

Was ist der Unterschied zwischen Sekunden und Millisekunden?

JavaScript, Java und viele APIs zählen Millisekunden, der Timestamp hat dann 13 statt 10 Stellen, 1700000000000. Der Rechner erkennt Werte über 100 Milliarden als Millisekunden. Wer die 13-stellige Zahl als Sekunden liest, landet im Jahr 55.000.

Was ist das Jahr-2038-Problem?

Ein 32-Bit-Zähler mit Vorzeichen endet bei 2147483647, dem 19. Januar 2038 um 03:14:07 UTC, und springt dann ins Jahr 1901. Moderne Systeme nutzen 64 Bit, aber eingebettete Geräte, alte Datenbankspalten und Dateiformate sind betroffen. Software mit 20-Jahres-Fristen hat schon Fehler gezeigt.

Warum beginnt die Unix-Zeit 1970?

Weil Ken Thompson und Dennis Ritchie 1971 ein rundes Datum nahe am Beginn von Unix brauchten, nachdem die erste Definition mit Sechzigstelsekunden seit 1971 nach 829 Tagen übergelaufen wäre. Eine tiefere Bedeutung hat das Datum nicht. Windows zählt seit 1601, Excel seit 1900, GPS seit 1980.

Berücksichtigt der Timestamp Schaltsekunden?

Nein. Die Unix-Zeit rechnet jeden Tag mit 86.400 Sekunden und ignoriert die 27 Schaltsekunden seit 1972. Bei einer Schaltsekunde wird die Uhr angehalten oder die Sekunde über Stunden verschmiert. Deshalb weicht die Unix-Zeit um 27 Sekunden von der Atomzeit TAI ab.

Wie rechne ich einen Timestamp in Excel um?

Mit der Formel Timestamp / 86400 + 25569 und dem Zellformat Datum und Uhrzeit, das ergibt UTC. Für deutsche Zeit im Winter plus 1/24, im Sommer plus 2/24, und 25569 ist der Excel-Wert für den 1. Januar 1970, weil Excel Tage seit 1900 zählt.

Stand: Oktober 2026Geprüft von: Redaktion rechner24.net Quellen: IEEE Std 1003.1 (POSIX): Seconds Since the Epoch, Dennis M. Ritchie, Ken Thompson: The UNIX Time-Sharing System, Communications of the ACM (1974), ISO 8601: Datenelemente und Austauschformate, Darstellung von Datum und Uhrzeit, IERS: Bulletin C, Schaltsekunden seit 1972