Unix-Zeitstempel-Umrechner

Beide Varianten sind verbreitet. Die klassische Unix-Zeit zählt Sekunden seit dem 1. Januar 1970 um 00:00 Uhr UTC. JavaScript (Date.now()) und viele Web-APIs liefern dagegen Millisekunden, also den tausendfachen Wert.

Am einfachsten unterscheidest du sie an der Stellenzahl: Ein Sekunden-Zeitstempel der Gegenwart hat zehn Stellen, ein Millisekunden-Zeitstempel dreizehn. Wandelt man einen Millisekunden-Wert versehentlich als Sekunden um, landet man tausende Jahre in der Zukunft. Der Unix-Zeitstempel-Umrechner erkennt die Einheit automatisch anhand der Länge. Den gesamten Praxisablauf mit UTC-Ausgabe, lokaler Anzeige, Tageslänge und Cron-Kontext ordnet der Ratgeber Zeitstempel und Zeitzonen in der Praxis ein.

Nein, ein Unix-Zeitstempel enthält keine Zeitzone. Er beschreibt einen Zeitpunkt als Zahl relativ zur Unix-Epoch, nicht eine Uhrzeit in Berlin, Wien, Zürich oder UTC.

Die Zeitzone kommt erst bei der Darstellung ins Spiel. Im Unix-Zeitstempel-Umrechner siehst du deshalb zwei Ansichten desselben Zeitpunkts: ISO 8601 (UTC) und Lokal (Europe/Berlin). Der Zeitstempel bleibt gleich; nur die angezeigte Uhrzeit ändert sich.

Wenn ein Timestamp „eine Stunde falsch” wirkt, ist meistens die Darstellung der Grund. Für Europe/Berlin liegt die lokale Uhrzeit je nach Datum typischerweise eine oder zwei Stunden vor UTC, weil Sommerzeit und Normalzeit unterschiedlich gelten. Prüfe im Umrechner beide Zeilen nebeneinander, bevor du den Wert selbst änderst. Eine andere Frage ist die Einheit: Ob dein Wert Sekunden oder Millisekunden enthält, erklärt die FAQ „Ist ein Unix-Zeitstempel in Sekunden oder Millisekunden?”. Ebenfalls eine andere Frage ist die Eingaberichtung: Welche Zeitzone gilt, wenn du selbst ein Datum in den Umrechner eintippst, erklärt die FAQ „Welche Zeitzone gilt für meine Datumseingabe?”. Wenn neben der Zeitzone auch UTC-Anzeige, Tageslänge oder Cron-Umgebung mitspielen, hilft der Ratgeber Zeitstempel und Zeitzonen in der Praxis beim systematischen Eingrenzen.

Eine Schaltsekunde ist eine zusätzliche Sekunde in UTC, mit der die koordinierte Weltzeit an die Erdrotation beziehungsweise UT1 angenähert wird. Sie wird nicht regelmäßig wie ein Schalttag eingefügt, sondern nur, wenn die Differenz zwischen UTC und der Erdrotationszeit groß genug wird. Die Grunddefinition von UTC steht im Glossar.

Warum UTC Schaltsekunden haben kann

UTC kombiniert eine atomare Zeitbasis mit dem Anspruch, nahe an der Erdrotation zu bleiben. Weil sich die Erde nicht vollkommen gleichförmig dreht, kann zwischen UTC und UT1 eine kleine Abweichung entstehen. Schaltsekunden sind der Mechanismus, mit dem UTC diese Abweichung begrenzt. Nach IERS-Regelwerk werden sie in Bulletin C angekündigt; praktisch kamen bisher Einfügungen am Ende von Juni oder Dezember vor.

Was das für Unix-Zeitstempel bedeutet

Für Entwickler ist der wichtigste Punkt: Unix-/POSIX-Zeit zählt Schaltsekunden nicht als eigene fortlaufende Sekunde mit. Ein Unix-Zeitstempel ist deshalb für normale Zeitpunkte und Vergleiche sehr praktisch, bildet aber nicht jede UTC-Schaltsekunde als separate Zähleinheit ab. Wer eine Zeitreihe sekundengenau mit offiziellen UTC-Markierungen vergleicht, muss diese Grenze kennen; für viele Alltagswerte reicht die normale Unix-Zeit trotzdem aus.

Daraus folgt keine einfache Aussage für alle Systeme. Betriebssysteme, Datenbanken, NTP-Dienste, Cloud-Plattformen oder Log-Pipelines können Leap Seconds unterschiedlich behandeln, zum Beispiel durch einen Zeitsprung oder durch eine verteilte Anpassung. Der Unix-Zeitstempel-Umrechner hilft beim Einordnen von Sekunden- und Millisekundenwerten; er ersetzt aber keine Prüfung, wie das konkrete Zielsystem Schaltsekunden verarbeitet. Den größeren Zusammenhang von Zeitstempeln, UTC und lokaler Anzeige erklärt der Ratgeber Zeitstempel und Zeitzonen in der Praxis.

Datenstand und Quellen

Datenstand: 2026-07-29. IERS Bulletin C 72 vom 2026-07-06 kündigt keine Schaltsekunde für Ende Dezember 2026 an und nennt UTC-TAI = -37 s ab 2017-01-01 bis auf Weiteres. Die BIPM/CGPM Resolution 4 von 2022 beschreibt die geplante Weiterentwicklung von UTC bis oder vor 2035. Diese Punkte sind vor Publishing gegen IERS Bulletin C, IERS Glossary und BIPM Resolution 4 zu prüfen.

Es kommt auf die Schreibweise deiner Eingabe an. Der Unix-Zeitstempel-Umrechner übergibt deinen Text an Date.parse, und die ECMAScript-Spezifikation legt für das Datum-Zeit-Format drei Fälle mit unterschiedlicher Zeitzonenannahme fest (ECMA-262, „Date Time String Format”, abgerufen am 2026-08-18):

• Nur ein Datum, z. B. 2026-07-13, wird als UTC-Mitternacht gelesen – auch wenn dein Rechner in Europe/Berlin steht.
• Datum mit Uhrzeit, aber ohne Offset, z. B. 2026-07-13T12:00:00, wird dagegen als Lokalzeit deines Geräts interpretiert – für die meisten Besucher in der DACH-Region Europe/Berlin. Dieselbe Uhrzeit ergibt so, je nachdem ob du das Datum drangeschrieben hast oder nicht, zwei unterschiedliche UTC-Zeitpunkte.
• Mit Z oder explizitem Offset, z. B. 2026-07-13T12:00:00Z oder …+02:00, ist die Eingabe eindeutig: Der Offset in der Eingabe entscheidet, nicht die Zeitzone deines Rechners, und das Ergebnis ist überall gleich.

Die Schreibweise 13.07.2026 gehört zu keinem der drei Fälle und scheitert: Date.parse liefert dafür NaN, der Umrechner meldet einen Fehler zum nicht erkannten Datum. Schreibe Tag, Monat und Jahr deshalb immer im ISO-8601-Format (JJJJ-MM-TT), nicht im deutschen Punktformat.

Am zuverlässigsten fährst du, wenn du den Offset (oder Z) immer mitschreibst, statt dich auf die Standardannahme zu verlassen – dann bleibt keine Zeitzone dem Parser überlassen, und dein Ergebnis stimmt mit dem deiner Kolleg:innen überein, egal in welcher Zeitzone sie gerade sitzen.

Das ist unabhängig davon, ob ein fertiger Zeitstempel selbst eine Zeitzone besitzt – dazu die FAQ „Hat ein Unix-Zeitstempel eine Zeitzone?”. Hintergrund zu UTC und Zeitzone liefert das Glossar.