Cookies für Statistik und Werbung
Wir setzen Cookies für Statistik und Werbung ein, beides geht an Google. Wenn du ablehnst, ändert sich für dich sichtbar nichts.Zur Datenschutzseite
Füge einen Unix-Zeitstempel ein und lies den Moment, den er bezeichnet — in UTC, in deiner eigenen Zeitzone mit ausgeschriebenem Versatz, als ISO-8601-Zeichenkette und als Wendung wie „vor acht Monaten“. Ob die Zahl Sekunden oder Millisekunden meint, wird aus ihrer Größe erschlossen, und die Antwort sagt, wofür sie sich entschieden hat.
Wo es läuft
Es wird nichts hochgeladen, weil es keine Datei gibt — gerechnet wird in dieser Seite.
Keine Warteschlange, kein Konto
Es antwortet so schnell, wie dein Rechner es hergibt, und fragt nie, wer du bist.
So oft du willst
Nichts wird gezählt und nichts begrenzt — noch einmal zu antworten kostet uns nichts.
Ein Unix-Zeitstempel zählt Sekunden seit dem 1. Januar 1970 UTC. JavaScript, Java und die meisten Log-Pipelines zählen stattdessen Millisekunden. Dieselben Ziffern bezeichnen also zwei Momente, die Jahrzehnte auseinanderliegen können, und der Zahl selbst sieht man nicht an, welche Konvention sie erzeugt hat.
In der Praxis entscheidet die Größe. Ein zehnstelliger Wert sind Sekunden bis zum Jahr 2286; ein dreizehnstelliger sind seit 1973 Millisekunden. Diese Seite wählt danach und sagt dir dann, wofür sie sich entschieden hat — und genau das lassen die meisten Umrechner weg. Wer still wählt und falsch liegt, zeigt ein Datum im Januar 1970 ohne jede Erklärung dazu.
UTC ist der Zeitstempel selbst: Ein Epoch-Wert trägt keine Zone, die UTC-Darstellung ist also eine Tatsache und keine Entscheidung. Die Zeile mit der Ortszeit ist die Einstellung deines Geräts, und der Versatz steht daneben, damit er nie mitgedacht werden muss.
Dieser Unterschied wiegt mehr, als er aussieht, wenn die Zahl von woanders kommt. Ein Zeitstempel aus einem Produktions-Log bezeichnet einen Moment, und der Moment ist überall derselbe — aber die Uhrzeit, die eine Kollegin aus demselben Log nennt, steht in ihrer Zone, und beim Vergleichen per Auge geht dort eine Stunde verloren. Vergleiche die UTC-Zeile oder die Zahl.
ISO 8601 mit abschließendem `Z` ist eindeutig: Sie nennt Moment, Zone und Genauigkeit in einer Zeichenkette, und jede Sprache liest sie. `2023-11-14T22:13:20.000Z` kann man nicht als Tag-Monat-Jahr oder Monat-Tag-Jahr missverstehen — dasselbe Datum mit Schrägstrichen sehr wohl.
Diese Mehrdeutigkeit ist nicht theoretisch. `03/04/2024` ist im größten Teil der Welt der 3. April und in den USA der 4. März, und eine Tabellenkalkulation legt das stillschweigend nach ihrer eigenen Ländereinstellung aus. Wenn ein Datum in ein Ticket, eine Nachricht oder ein anderes System geht, ist die ISO-Form die, die heil ankommt.
ISO-8601-Wochen beginnen am Montag, und Woche 1 ist die Woche, die den ersten Donnerstag des Jahres enthält. Der 1. Januar kann damit zu Woche 52 oder 53 des Vorjahres gehören — der 1. Januar 2021 liegt in 2020-W53 —, und ein Jahr kann 53 Wochen haben.
Die naheliegende Implementierung, den Tag des Jahres durch sieben zu teilen, widerspricht dem jedes Jahr etwa zwei Wochen lang. Das ist relevant, weil ISO-Wochen das sind, womit Berichtssysteme, Lohnbuchhaltung und der größte Teil Europas rechnen: Ein Bericht mit der Überschrift „KW 1“ kann Tage aus zwei Jahren umfassen und völlig korrekt sein.
Eine vorzeichenbehaftete 32-Bit-Zahl, die Sekunden hält, läuft am 19. Januar 2038 über. Systeme, die `time_t` noch als 32-Bit-Wert führen, springen auf 1901 — dieselbe Form von Problem wie das Jahr 2000, mit kleinerer Reichweite und schwierigerer Behebung, weil es Firmware und alte Dateiformate betrifft und nicht Geschäftssoftware.
Für diese Seite und für alles, was in den letzten zehn Jahren in einer verbreiteten Sprache geschrieben wurde, gilt es nicht. JavaScript rechnet mit Gleitkommazahlen doppelter Genauigkeit und hält Millisekunden exakt bis zum Jahr 275760; 64-Bit-`time_t` reicht länger, als das Universum existiert. Wer einen Zeitstempel im Browser ansieht, hat mit 2038 nichts zu tun.
Ein Datum im Jahr 1970 heißt fast immer, dass Millisekunden als Sekunden gelesen wurden — oder dass der Wert null oder leer war und etwas ihn zu null gemacht hat, was der Epoch-Moment selbst ist. Ein Datum in ferner Zukunft heißt meist das Umgekehrte: Sekunden als Millisekunden gelesen, oder ein Zeitstempel in Mikro- oder Nanosekunden, wie ihn manche Datenbanken und Tracing-Systeme ausgeben.
Mikrosekunden haben sechzehn Stellen, Nanosekunden neunzehn. Beides wird hier nicht automatisch erkannt, denn beides ist selten genug, dass ein Raten darauf die häufige Schätzung verschlechtern würde. Teile vorher durch tausend oder eine Million, dann fällt der Wert in einen Bereich, den diese Seite richtig liest.
Tausendertrennzeichen, Unterstriche und Leerraum werden entfernt, weil ein aus formatierter Ausgabe kopierter Zeitstempel sie mitbringt. Ein Nachkommateil bleibt erhalten: Pythons `time.time()` liefert eine Gleitkommazahl, und ihn stillschweigend abzuschneiden würde eine Genauigkeit unter einer Sekunde wegwerfen, die jemand vielleicht bewusst eingefügt hat.
Nicht akzeptiert wird alles, was keine Zahl ist — kein Datum, keine wissenschaftliche Schreibweise, kein Hexadezimalwert. Das ist Absicht: Ein Umrechner, der `2024-01-01` irgendwie zu deuten versucht, beantwortet eine andere Frage als die gestellte, und zwar meist falsch.
Zeitstempel wirken selten heikel. Sie kommen allerdings aus Logs und Payloads, die es oft sind — und der Zeitstempel steht selten allein im Zwischenspeicher, wenn jemand eine Zeile kopiert.
Die Rechnung ist eine Multiplikation und ein Aufruf der eingebauten Datumsbibliothek; dafür einen Server zu bemühen, wäre in jeder Hinsicht der schlechtere Weg. Das Netzwerk-Panel zeigt beim Tippen nichts.
Ein Unix-Zeitstempel kennt keine Sommerzeit, weil er UTC zählt — und das ist genau seine Stärke. Die Umstellung passiert erst in der Zeile mit der Ortszeit, wo aus derselben Zahl je nach Datum MEZ oder MESZ wird, und der Versatz daneben sagt, welche gerade gilt.
Das erklärt eine wiederkehrende Verwirrung: Zwei Zeitstempel, die exakt eine Stunde auseinanderliegen, können in Ortszeit dieselbe Uhrzeit tragen — in der Nacht der Rückstellung gibt es 02:30 zweimal. Wer Ereignisse über diese Nacht hinweg sortiert, sortiert nach der Zahl und nicht nach der angezeigten Uhrzeit.
Postgres speichert `timestamptz` intern als Mikrosekunden seit dem Jahr 2000 und gibt beim Lesen ein Datum aus; die Epoch-Sekunden bekommt man erst über `extract(epoch from …)`. MySQL kennt beides nebeneinander: `TIMESTAMP` ist ein Unix-Wert in Sekunden mit dem bekannten Ende 2038, `DATETIME` ist eine Wanduhr ohne Zone. SQLite hat gar keinen Datumstyp und speichert, was die Anwendung hineinschreibt.
Deshalb liegen in einer Spalte, die „timestamp“ heißt, je nach System Sekunden, Millisekunden, Mikrosekunden oder eine Zeichenkette. Wer eine unbekannte Spalte vor sich hat, zählt die Stellen: zehn, dreizehn, sechzehn — und danach richtet sich, ob hier direkt eingefügt oder vorher geteilt werden muss.
Weil Berichte in Kalenderwochen laufen und Logs in Zeitstempeln. Die Brücke zwischen beidem von Hand zu schlagen ist mühsam und fehleranfällig, und sie steht deshalb gleich mit in der Antwort — samt Jahr, denn genau dort geht es schief.
Die Schreibweise `2020-W53` ist die aus ISO 8601 und trägt das Wochenjahr, nicht das Kalenderjahr. Für den 1. Januar 2021 steht dort 2020, und das ist korrekt: Die Woche gehört zum Vorjahr. Ein Bericht, der stattdessen „KW 53/2021“ sagt, meint eine Woche, die es nicht gibt.
Zähl die Stellen. Zehn heißt Sekunden für jedes Datum zwischen 2001 und 2286, dreizehn heißt Millisekunden. Diese Seite entscheidet danach und nennt die verwendete Einheit, damit du sie überstimmen kannst, wenn die Zahl aus etwas Ungewöhnlichem stammt.
Fast immer, weil Millisekunden als Sekunden gelesen wurden — ein dreizehnstelliger Wert als Sekunden landet weit in der Zukunft, ein zehnstelliger als Millisekunden knapp drei Wochen nach der Epoche. Die andere Ursache ist ein Wert, der null oder leer war, denn der Epoch-Moment selbst ist der 1. Januar 1970.
In der, auf die dieses Gerät eingestellt ist, mit dem Versatz daneben. Es gibt hier keinen Server und keine konfigurierte Zone. Wenn du gegen die Lesart einer Kollegin aus demselben Log vergleichst, vergleiche die UTC-Zeile oder die Zahl selbst — dort geht sonst eine Stunde verloren.
Weil ISO-Wochen am Montag beginnen und Woche 1 die mit dem ersten Donnerstag des Jahres ist. Der 1. Januar 2021 fällt in Woche 53 des Jahres 2020, und manche Jahre haben 53 Wochen. Den Tag des Jahres durch sieben zu teilen ergibt jährlich etwa zwei Wochen lang eine andere Antwort.
Nein. Die Rechnung passiert in dieser Seite, und das Netzwerk-Panel zeigt nichts. Zeitstempel wirken selten heikel, kommen aber aus Logs und Payloads, die es oft sind — und es gibt keinen Grund, warum einer für eine Multiplikation reisen müsste.