Woher weiß es, ob meine Zahl Sekunden oder Millisekunden sind?

Aus ihrer Größenordnung: Werte unterhalb von etwa 1e11 werden als Sekunden gelesen, größere als Millisekunden. Heute trennt das zehnstellige Sekunden sauber von dreizehnstelligen Millisekunden. Die Lesart steht neben dem Ergebnis und lässt sich mit einem Klick umschalten — die Vermutung wird Ihnen also nie verheimlicht.

Welche Zeitzone gilt als „lokal“?

Die, die Ihr eigenes Gerät meldet, im Browser erkannt und mit Namen angezeigt, damit kein Zweifel bleibt. Es ist Ihre Zone, nicht die der Website: Wer aus Berlin kommt, sieht Berliner Zeit, wer aus Tokio kommt, die Zeit in Tokio.

Kann ich ein Datum zurück in einen Zeitstempel umwandeln?

Ja. Dasselbe Feld nimmt beide Richtungen an: Geben Sie eine Zahl ein und Sie bekommen ein Datum; geben Sie ein Datum wie 2024-05-20 oder 2024-05-20T09:33:20Z ein und Sie bekommen den Epoch-Wert zurück. Es gibt keinen Modus zum Umschalten.

Kommt es mit Daten vor 1970 zurecht?

Ja. Zeitstempel vor der Epoch sind einfach negativ — -86400 ist der 31. Dezember 1969 — und negative Werte werden ganz normal angenommen und umgerechnet.

Warum zeigt mein Zeitstempel ein anderes Datum als erwartet?

Fast immer aus einem von zwei Gründen: Die Sekunden-/Millisekunden-Lesart ist nicht die, die Sie angenommen haben (prüfen Sie die Beschriftung und schalten Sie um), oder Sie vergleichen einen UTC-Wert mit einer Erwartung in Ortszeit. Das Werkzeug zeigt beide Zeilen nebeneinander, damit Sie sehen, welcher Fall vorliegt.

Was ist das Jahr-2038-Problem?

Systeme, die Epoch-Sekunden in einer vorzeichenbehafteten 32-Bit-Ganzzahl speichern, laufen am 19. Januar 2038 über und springen auf eine negative Zahl, was Daten im Jahr 1901 ergibt. Alles, was 64-Bit-Werte verwendet — also nahezu alles Moderne — ist nicht betroffen, aber alte eingebettete Systeme und ältere Datenbankspalten können weiterhin gefährdet sein.

Warum ist mein Zeitstempel achtzehn Stellen lang?

Weil er wahrscheinlich kein Unix-Zeitstempel ist. Unix-Sekunden haben heute zehn Stellen und Unix-Millisekunden dreizehn; achtzehn Stellen hat ein Hundert-Nanosekunden-Tick, und den zählt Windows FILETIME ab 1601 und .NET ab dem Anfang des Jahres 1. Sechzehn Stellen sind der andere häufige Fall — derselbe Augenblick in Mikrosekunden. Der Abschnitt über Epochs weiter oben nennt die Zahl, die jeweils abzuziehen ist.

Wie wandle ich in Python ein Datum in einen Unix-Zeitstempel um?

Bauen Sie ein zeitzonenbewusstes datetime — eines, das ein tzinfo trägt — rufen Sie dessen timestamp-Methode auf und schneiden Sie das Ergebnis auf eine ganze Zahl ab. Der Codeblock weiter oben enthält die Zeile, und derselbe Abschnitt zeigt dieselbe Aufgabe in der Shell und in JavaScript. Die ganze Schwierigkeit steckt im tzinfo: Lassen Sie es weg, und Python liest Ihre Zahlen als Ortszeit der Maschine und gibt einen anderen Wert zurück, ohne es zu sagen.

Wird der Zeitstempel, den ich eingebe, irgendwohin gesendet?

Nein. Auswerten, Umrechnen und Formatieren laufen vollständig in Ihrem Browser, gestützt auf die eigene Datums- und Zeitzonenunterstützung der Plattform. Nichts, was Sie eingeben, verlässt Ihr Gerät.

Unix-Zeitstempel-Konverter

Einen Unix-Zeitstempel in ein Datum in jeder Zeitzone wandeln und zurück: Sekunden oder Millisekunden werden erkannt, dazu ISO 8601 und wie lange es her ist.

Aktuelle Unix-Zeit

Wird ermittelt…

Eingabe

Was ein Unix-Zeitstempel ist

Ein Unix-Zeitstempel — auch Epoch-Zeit oder POSIX-Zeit genannt — ist eine einzelne Zahl, die zählt, wie viele Sekunden seit dem 1. Januar 1970 um 00:00:00 UTC vergangen sind, einem Moment, der als Unix-Epoch bekannt ist. Weil es eine einzige ganze Zahl ist, ohne Zeitzone, ohne Kalender und ohne Formatierung, greifen Computer immer dann darauf zurück, wenn ein Zeitpunkt gespeichert, sortiert, verglichen oder über ein Netzwerk verschickt werden muss. Das steckt hinter der Spalte „created_at“ in Ihrer Datenbank, hinter den Claims „iat“ und „exp“ in einem JWT, hinter der mtime einer Datei und hinter den Zeitstempeln in nahezu jeder Logdatei, die Sie je lesen werden.

Der Preis dafür ist, dass eine nackte Zahl einem Menschen nichts sagt. 1716197600 ist ein völlig gültiger Zeitpunkt, aber man sieht ihr nicht an, ob sie letzten Dienstag meint oder vor drei Jahren. Genau diese Übersetzung, in beide Richtungen, leistet dieses Werkzeug.

Sekunden oder Millisekunden — die Mehrdeutigkeit, die zubeißt

Die ursprüngliche Unix-Konvention zählt ganze Sekunden, und das liefern date +%s in der Shell, time() in PHP und time.time() in Python nach dem Abschneiden. JavaScript, Java und viele andere zählen stattdessen Millisekunden: Date.now() gibt eine tausendmal größere Zahl zurück. Beides heißt „Zeitstempel“, und beides zu verwechseln gehört zu den häufigsten Datumsfehlern überhaupt.

Der Fehler ist leise statt laut. Liest man einen Millisekundenwert als Sekunden, landet das Datum Zehntausende Jahre in der Zukunft; liest man einen Sekundenwert als Millisekunden, fällt alles auf Januar 1970 zusammen. Keiner der beiden Fälle wirft einen Fehler — man bekommt schlicht ein falsches Datum, das wie ein echtes aussieht.

Dieses Werkzeug rät anhand der Größenordnung der Zahl und sagt Ihnen dann, was es geraten hat, direkt neben dem Ergebnis. Heutige Epoch-Sekunden haben zehn Stellen und heutige Epoch-Millisekunden dreizehn, die Vermutung stimmt also fast immer — aber „fast“ genügt nicht für einen Wert, den Sie gleich in einen Fehlerbericht einfügen. Deshalb ist die Lesart immer sichtbar und immer nur einen Klick vom Umschalten entfernt.

Zeitzonen, UTC und warum „lokal“ glitschig ist

Ein Unix-Zeitstempel hat keine Zeitzone. Er bezeichnet einen Augenblick: 1716197600 ist 2024-05-20T09:33:20Z, und derselbe Augenblick ist gleichzeitig 10:33 in London, 12:33 in Jerusalem und 18:33 in Tokio — in London und Jerusalem gilt an diesem Tag die Sommerzeit, in Japan gibt es gar keine. Eine Zeitzone ist nicht Teil des Werts; sie ist die Linse, durch die Sie ihn betrachten.

Deshalb zeigt dieses Werkzeug mehrere Linsen gleichzeitig. UTC ist die neutrale Referenz, auf die sich jeder Server und jedes Log einigen. Ihre Ortszeit ist das, was Ihr eigenes Gerät meldet, angezeigt mit dem Namen der Zone (etwa Europe/Berlin), damit Sie immer wissen, welche Linse sie erzeugt hat — die Erkennung passiert in Ihrem Browser, ein Besucher in Berlin sieht also Berliner Zeit und ein Besucher in Tokio die Zeit in Tokio. Die dritte Zeile ist eine beliebige Zone aus der vollständigen IANA-Zeitzonendatenbank — genau die Zeile, die Sie brauchen, wenn Sie ein Log von einem Server lesen, der anderswo steht.

UTC — die Referenz, auf die sich alle Systeme einigen, und das Richtige zum Speichern und Protokollieren.
Lokal — derselbe Augenblick, wie ihn Ihr Gerät sieht, beschriftet mit der erkannten Zone.
Eine Zone Ihrer Wahl — zum Lesen von Logs und Traces von Maschinen anderswo.
ISO 8601 — das Austauschformat als Text, z. B. 2024-05-20T09:33:20.000Z.
Relativ — „vor 3 Stunden“, für ein schnelles Gefühl dafür, wie aktuell etwas ist.

Die Abweichungen stehen neben jeder Zeit (+03:00, -04:00), weil sie nicht fest sind: Die meisten Zonen verschieben sich zur Sommerzeit um eine Stunde, dieselbe Zone kann also je nach Jahreszeit verschiedene Abweichungen ergeben. Ein Datum kurz vor oder nach einer Umstellung ist genau die Stelle, an der Kopfrechnen schiefgeht.

Mit Epoch-Zeit in der Praxis arbeiten

Jede Sprache und jede Shell hat ihren eigenen Weg, Epoch-Werte zu erzeugen und zu lesen. Diese lohnt es sich zu merken:

date +%s                         # Shell: aktuelle Zeit in Sekunden
date -d @1716197600              # Shell (GNU): von Sekunden zum Datum
Date.now()                       # JavaScript: aktuelle Zeit in MILLIsekunden
new Date(1716197600 * 1000)      # JavaScript: von Sekunden zu Date
time.time()                      # Python: Sekunden, als Fließkommazahl
datetime.fromtimestamp(1716197600, tz=timezone.utc)
SELECT EXTRACT(EPOCH FROM now()) -- PostgreSQL: Sekunden

Eine Faustregel, die den meisten Datumsärger vermeidet: Speichern und übertragen Sie Zeitpunkte als UTC — entweder als Epoch-Ganzzahl oder als ISO-8601-Zeichenkette — und rechnen Sie erst im letzten Moment in eine lokale Zone um, wenn Sie sie tatsächlich jemandem anzeigen. Zu frühes Formatieren ist der Weg, auf dem ein Zeitzonenfehler in Ihre Daten eingebacken wird, statt in der Anzeigeschicht zu bleiben.

Noch etwas Wissenswertes: Ein vorzeichenbehafteter 32-Bit-Sekundenzähler läuft am 19. Januar 2038 über — das „Jahr-2038-Problem“. Moderne Systeme verwenden 64-Bit-Werte und sind sicher, aber alte eingebettete Geräte und ältere Datenbankspalten sind genau die Orte, an denen Sie ihm noch begegnen können.

Was eine Epoch ist — und warum nicht jeder Zeitstempel bei 1970 beginnt

Eine Epoch ist in diesem Sinne einfach eine gewählte Null — der Augenblick, ab dem ein Zähler per Definition zu zählen beginnt. Die Unix-Epoch ist der 1. Januar 1970 um 00:00:00 UTC, und sie wurde gewählt, weil das ein bequemes rundes Datum war, nicht weil sie sich aus irgendetwas herleitet: nichts am Format verlangt gerade diesen Tag. Das frühe Unix zählte Sechzigstelsekunden ab einer viel näheren Null, und das Handbuch der dritten Auflage sagte deutlich, warum das nicht halten konnte — zweiunddreißig Bit Sechzigstel garantieren alle 2,26 Jahre eine Krise, also etwa alle 828 Tage. Ganze Sekunden in denselben zweiunddreißig Bit reichen hundertsechsunddreißig Jahre weit, oder achtundsechzig, wenn der Zähler ein Vorzeichen hat — das ist das Datum 2038 weiter oben.

Diese Vorgeschichte ist der Grund, eine lange Zahl zu prüfen, bevor man ihr traut. Andere Systeme zählen ab anderen Nullen und in anderen Auflösungen, und eine davon als Unix-Sekunden zu lesen, bringt Sie nicht um ein paar Stunden daneben — es bringt Sie um Jahrhunderte daneben. Diese begegnen Ihnen am ehesten:

Windows FILETIME — Hundert-Nanosekunden-Ticks seit dem 1. Januar 1601 UTC. Durch zehn Millionen teilen und 11644473600 abziehen ergibt Unix-Sekunden; der in diesem Leitfaden durchgehend verwendete Augenblick 1716197600 ist dort 133606712000000000.
.NET DateTime.Ticks — derselbe Hundert-Nanosekunden-Tick, aber gezählt ab dem Anfang des Jahres 1. Die Unix-Epoch selbst liegt bei 621355968000000000 Ticks, und das ist die Zahl, die vor dem Teilen abzuziehen ist.
Apples Referenzdatum — Sekunden seit dem 1. Januar 2001 UTC, verwendet von Cocoa und Core Data. Addieren Sie 978307200 für Unix-Sekunden: 1716197600 ist dort 737890400.
Serienzahlen in Excel — Tage statt Sekunden, gezählt ab dem 30. Dezember 1899, weil Excel 1900 als Schaltjahr behandelt, das es nicht war.
GPS-Zeit — Sekunden seit dem 6. Januar 1980, gezählt ohne je eine Schaltsekunde zu überspringen, sodass GPS-Zeit und UTC nicht mehr übereinstimmen.

Der letzte Punkt weist auf etwas hin, das für den Unix-Wert selbst gilt: Er ist keine Stoppuhr-Ablesung. POSIX definiert ihn als einen Wert, der die seit der Epoch vergangenen Sekunden annähert, und verlangt, dass jeder einzelne Tag mit genau 86400 Sekunden verbucht wird — die in UTC eingefügten Schaltsekunden werden also überhaupt nicht mitgezählt. Der Abstand zwischen zwei Unix-Zeitstempeln ist damit die Zahl der Kalendersekunden zwischen ihnen und nicht die Zahl der tatsächlich vergangenen, und der Wert versteht sich am besten als Kodierung einer UTC-Kalenderablesung. Es ist auch der Grund, warum kein Zeitstempel je eine Schaltsekunde benennt: die Kodierung hat keinen Platz für eine.

Aus einem Datum einen Epoch-Wert machen: Shell, JavaScript und Python

Der Block weiter oben macht aus einem Epoch-Wert etwas Lesbares. Die Gegenrichtung — ein Datum, das Sie schon haben, als Text oder als Satz von Zahlen, wird zu einem Epoch-Wert — ist die Stelle, an der die Zeitzonenfehler wohnen, denn jede dieser Sprachen nimmt stillschweigend eine Zone an, wenn der Text keine nennt. Hier ist dieselbe Aufgabe auf drei Arten, am Augenblick 2024-05-20T09:33:20Z aus diesem Leitfaden. Die Shell-Zeilen sind GNU date; das date von BSD und macOS nimmt andere Optionen.

date -u -d '2024-05-20 09:33:20' +%s     # 1716197600 — -u liest den Text als UTC
date -d '2024-05-20 09:33:20 UTC' +%s    # dasselbe, mit der Zone im Text benannt
date -d '2024-05-20 09:33:20' +%s        # keins von beidem: die Zone Ihrer Maschine

Date.parse('2024-05-20T09:33:20Z') / 1000    // 1716197600 — das Z macht es zu UTC
new Date('2024-05-20T09:33:20Z').getTime()   // derselbe Augenblick in Millisekunden
Date.parse('2024-05-20 09:33:20')            // ohne Z: die Zone Ihrer Maschine

from datetime import datetime, timezone
int(datetime(2024, 5, 20, 9, 33, 20, tzinfo=timezone.utc).timestamp())   # 1716197600 — zeitzonenbewusst
int(datetime.fromisoformat('2024-05-20T09:33:20+00:00').timestamp())     # dasselbe, aus einer Zeichenkette
int(datetime(2024, 5, 20, 9, 33, 20).timestamp())                        # naiv: die Zone Ihrer Maschine

Das Muster ist in allen dreien dasselbe: Nennen Sie die Zone, sonst erben Sie die, auf die die Maschine eingestellt ist. Eine Zahl, die auf Ihrem Laptop stimmt und auf dem einer Kollegin um Stunden danebenliegt, ist fast immer genau das — und deshalb zeigt das Werkzeug oben UTC und Ihre Ortszeit nebeneinander, statt eine davon für Sie auszuwählen. Wenn Sie die Zahl schon haben und sie mit dem Auge prüfen wollen, fügen Sie sie oben auf dieser Seite in das Feld ein.

Häufig gestellte Fragen

Woher weiß es, ob meine Zahl Sekunden oder Millisekunden sind?: Aus ihrer Größenordnung: Werte unterhalb von etwa 1e11 werden als Sekunden gelesen, größere als Millisekunden. Heute trennt das zehnstellige Sekunden sauber von dreizehnstelligen Millisekunden. Die Lesart steht neben dem Ergebnis und lässt sich mit einem Klick umschalten — die Vermutung wird Ihnen also nie verheimlicht.
Welche Zeitzone gilt als „lokal“?: Die, die Ihr eigenes Gerät meldet, im Browser erkannt und mit Namen angezeigt, damit kein Zweifel bleibt. Es ist Ihre Zone, nicht die der Website: Wer aus Berlin kommt, sieht Berliner Zeit, wer aus Tokio kommt, die Zeit in Tokio.
Kann ich ein Datum zurück in einen Zeitstempel umwandeln?: Ja. Dasselbe Feld nimmt beide Richtungen an: Geben Sie eine Zahl ein und Sie bekommen ein Datum; geben Sie ein Datum wie 2024-05-20 oder 2024-05-20T09:33:20Z ein und Sie bekommen den Epoch-Wert zurück. Es gibt keinen Modus zum Umschalten.
Kommt es mit Daten vor 1970 zurecht?: Ja. Zeitstempel vor der Epoch sind einfach negativ — -86400 ist der 31. Dezember 1969 — und negative Werte werden ganz normal angenommen und umgerechnet.
Warum zeigt mein Zeitstempel ein anderes Datum als erwartet?: Fast immer aus einem von zwei Gründen: Die Sekunden-/Millisekunden-Lesart ist nicht die, die Sie angenommen haben (prüfen Sie die Beschriftung und schalten Sie um), oder Sie vergleichen einen UTC-Wert mit einer Erwartung in Ortszeit. Das Werkzeug zeigt beide Zeilen nebeneinander, damit Sie sehen, welcher Fall vorliegt.
Was ist das Jahr-2038-Problem?: Systeme, die Epoch-Sekunden in einer vorzeichenbehafteten 32-Bit-Ganzzahl speichern, laufen am 19. Januar 2038 über und springen auf eine negative Zahl, was Daten im Jahr 1901 ergibt. Alles, was 64-Bit-Werte verwendet — also nahezu alles Moderne — ist nicht betroffen, aber alte eingebettete Systeme und ältere Datenbankspalten können weiterhin gefährdet sein.
Warum ist mein Zeitstempel achtzehn Stellen lang?: Weil er wahrscheinlich kein Unix-Zeitstempel ist. Unix-Sekunden haben heute zehn Stellen und Unix-Millisekunden dreizehn; achtzehn Stellen hat ein Hundert-Nanosekunden-Tick, und den zählt Windows FILETIME ab 1601 und .NET ab dem Anfang des Jahres 1. Sechzehn Stellen sind der andere häufige Fall — derselbe Augenblick in Mikrosekunden. Der Abschnitt über Epochs weiter oben nennt die Zahl, die jeweils abzuziehen ist.
Wie wandle ich in Python ein Datum in einen Unix-Zeitstempel um?: Bauen Sie ein zeitzonenbewusstes datetime — eines, das ein tzinfo trägt — rufen Sie dessen timestamp-Methode auf und schneiden Sie das Ergebnis auf eine ganze Zahl ab. Der Codeblock weiter oben enthält die Zeile, und derselbe Abschnitt zeigt dieselbe Aufgabe in der Shell und in JavaScript. Die ganze Schwierigkeit steckt im tzinfo: Lassen Sie es weg, und Python liest Ihre Zahlen als Ortszeit der Maschine und gibt einen anderen Wert zurück, ohne es zu sagen.
Wird der Zeitstempel, den ich eingebe, irgendwohin gesendet?: Nein. Auswerten, Umrechnen und Formatieren laufen vollständig in Ihrem Browser, gestützt auf die eigene Datums- und Zeitzonenunterstützung der Plattform. Nichts, was Sie eingeben, verlässt Ihr Gerät.