Ist diese lange Zahl ein Zeitstempel? Millisekunden vs Sekunden

Zuletzt geprueft 2026-05-03. Sie haben eine 10-, 13-, 16- oder 19-stellige Zahl aus einem Server-Log, einer API-Antwort oder einer Datenbankzeile eingefuegt und muessen jetzt wissen, was es ist. Diese Anleitung ist der 30-Sekunden-Test - zaehlen Sie die Ziffern, machen Sie einen Sanity-Check des Jahres, leiten Sie zum richtigen Konverter weiter.

Der 30-Sekunden-Test: zaehlen Sie die Ziffern

Die dominanten Unix-Zeitstempel-Formate codieren Zeit als Anzahl von "Ticks seit 1970-01-01 00:00:00 UTC". Die Tick-Groesse unterscheidet sich - Sekunden, Millisekunden, Mikrosekunden, Nanosekunden - und das aendert, wie viele Ziffern die Zahl zu einem bestimmten Zeitpunkt in 2026 hat. Heute (2026), hier ist die Daumenregel fuer die Ziffernanzahl:

Warum die meisten Zahlen, die Sie im Web sehen, Millisekunden sind

JavaScripts Date.now(), Javas System.currentTimeMillis() und die meisten modernen JSON-emittierenden Backends sind standardmaessig auf Millisekunden seit der Unix-Epoche eingestellt. Dieser Moment - 2026-05-03 09:38:00 UTC - ist 1777800999 in Sekunden (10 Ziffern), aber 1777800999000 in Millisekunden (13 Ziffern). Die 13-stellige Form landet in Netzwerkantworten, Browser-Dev-Tool-Konsolen, Log-Zeilen und Dashboards mehr als jede andere Zeitstempel-Form, weshalb die haeufigste Leserfrage fuer diese Art von Zeitstempel "dies ist eine 13-stellige Zahl, welches Datum ist es?" ist.

Diese Beobachtung gibt Ihnen einen schnellen Sanity-Check: Wenn Ihre Zahl 13 Ziffern hat und mit 1777 beginnt, ist es fast sicher eine Unix-Millisekunde vom Mai 2026. Wenn sie mit 16 oder 17 in 2026 beginnt, ist sie im richtigen Bereich. Wenn sie mit 1 gefolgt von irgendetwas (z.B. 1234567890123) beginnt, sollten Sie sie trotzdem in ein Datum konvertieren und das Jahr ueberpruefen, bevor Sie annehmen - falsche Testdaten waehlen oft Vanity-Nummern wie 1234567890, die als 2009 (Freitag 13. Februar) gerendert werden.

Wenn die Zahl KEIN Zeitstempel ist

Mehrere lange Zahlen sehen wie Zeitstempel aus, sind es aber nicht:

• Snowflake- / Twitter- / Discord-IDs (typischerweise 18-19 Ziffern). Diese codieren einen Zeitstempel in ihren hohen Bits, aber die niedrigen Bits sind Worker-IDs und Sequenz-Zaehler; die gesamte 19-stellige Zahl als Unix-Nanosekunde zu behandeln, wird ein voellig falsches Datum produzieren. Snowflake-Decodierung erfordert eine Bit-Verschiebung, keine Division.
• UUIDv7 (32 Hex-Ziffern, aber die ersten 12 Hex-Zeichen codieren Millisekunden). Wenn Sie 32 Hex-Zeichen mit Bindestrichen formatiert haben, ist das eine UUID, kein Zeitstempel - konvertieren Sie nur die ersten 48 Bits, wenn Sie die eingebettete Zeit brauchen.
• Datenbank-BIGINT-Sequenz-IDs. Diese sind automatisch erhoehte Integer und haben keine Zeitkomponente; sie wachsen zufaellig in den 12-13-Ziffern-Bereich, wenn die Sequenz fortschreitet. Schneller Check: Wenn dieselbe Spalte auf benachbarten Zeilen um 1 (oder um einen kleinen vorhersehbaren Schritt) abweicht, ist es eine Sequenz, kein Zeitstempel.
• Telefonnummern, die als Integer gespeichert sind. Eine 10-12-stellige Zahl, die mit einem Landesvorwahl-Praefix beginnt (z.B. 1212 fuer New York), kann eine Telefonnummer sein, die ohne Trennzeichen gerendert wurde. Konvertieren Sie und ueberpruefen: Wenn das resultierende Jahr vor 1970 oder nach 2100 ist, ist es kein Unix-Zeitstempel.
• Konto- / Bestellnummern. Padding-Stil-Zahlen wie 1000000123 (10 Ziffern, aber kein Unix-Sekunden-Wert) haben gewoehnlich ein Fix-Breiten-Praefix, das sie verraet - sie wachsen nicht stetig im Laufe der Zeit.

Die guenstigste Disambiguierung ist, die Zahl in den Millisekunden-Konverter einzufuegen und das Jahr zu betrachten. Wenn das Ergebnis in 1970 ist (Zahl war eigentlich Sekunden, Sie haben sie als ms behandelt) oder in einem fernen Zukunftsjahr wie 56.000 (Zahl war Millisekunden, Sie haben sie als Sekunden behandelt), sagt Ihnen die Ziffernanzahl, in welche Richtung Sie konvertieren. Wenn das Ergebnis plausibel ist (2025-2027 fuer Live-Daten, 1990-2025 fuer historische Daten), haben Sie Ihre Antwort.

Schnelles Konvertierungs-Playbook

Drei Schritte, keine Mathematik:

1. Ziffern zaehlen. 10 Ziffern = Sekunden; 13 = Millisekunden; 16 = Mikrosekunden; 19 = Nanosekunden; sonst siehe vorigen Abschnitt.
2. In den richtigen Konverter einfuegen. 13-stellige Zahlen gehen direkt in den Millisekunden-zu-Datum-Konverter. 10-stellige Sekunden: drei Nullen anhaengen (also wird 1777800999 zu 1777800999000) und einfuegen. 16-stellige Mikrosekunden: die letzten drei Ziffern abschneiden. 19-stellige Nanosekunden: die letzten sechs Ziffern abschneiden. Der Konverter zeigt das resultierende UTC-Datum und Ihr lokales Datum.
3. Sanity-Check des Jahres. Wenn das Jahr unerwartet ist (1970 oder 56000), haben Sie in die falsche Richtung konvertiert. Lesen Sie die Ziffernanzahl erneut und versuchen Sie es nochmal. Wenn das Jahr plausibel ist, haben Sie den richtigen Wert.

Fuer das umgekehrte Problem - "gib mir die aktuellen Unix-Millisekunden, damit ich vergleichen kann" - oeffnen Sie das aktuelle Unix-Millisekunden-Tool; es tickt live und kopiert in die Zwischenablage. Zwei Zeitstempel zu vergleichen ist der schnellste Weg, um zu bestaetigen, ob Ihre Zahl "jetzt-ish" oder veraltete Daten ist.

Haeufig gestellte Fragen

Was ist mit 11- oder 12-stelligen Zahlen? Sie sehen fast wie Sekunden aus.
Unix-Sekunden werden bis zum Jahr 2286 keine 11 Ziffern produzieren. Unix-Millisekunden waren zwischen 2001 (10^12 ms = 31,7 Jahre nach 1970) und 2286 12 Ziffern. Eine 12-stellige Zahl der aktuellen Aera ist also wahrscheinlich eine Sequenz-ID oder eine Telefonnummer; eine 11-stellige Zahl ist fast sicher kein aktueller Unix-Wert irgendeiner Art.

Die Zahl ist negativ oder beginnt mit einem Minuszeichen. Ist das ein Zeitstempel?

Ja - negative Unix-Zeitstempel sind Daten vor 1970-01-01 UTC. -1000000000 Sekunden ist 1938-04-24. Die meisten Sprach-Standardbibliotheken handhaben negative Sekunden korrekt; einige Web-Tools weisen sie ab. Der Millisekunden-Konverter akzeptiert negative Eingaben.

Warum gibt dasselbe Datum auf zwei Systemen eine andere Zahl?

Die Zahl selbst ist zeitzonenfrei (Unix-Zeit ist immer UTC). Was sich unterscheidet, ist, wie jedes System die Zahl in eine lesbare Zeichenkette rendert - ein Tool kann UTC waehlen, ein anderes Ihre lokale Zeitzone. Die zugrunde liegende Unix-Integer-Zahl ist dieselbe. Wenn zwei Systeme uneinig sind ueber die Zahl fuer denselben Moment, verwendet eines davon eine andere Einheit (Sekunden vs Millisekunden) oder eine andere Epoche (z.B. Excel verwendet 1900-01-01 als seine Epoche, was nicht Unix-Zeit ist).

Kann ich Bruchteilsekunden aus einem 10-stelligen Unix-Wert herausbekommen?

Nein - ein 10-stelliger Sekunden-Wert hat 1-Sekunden-Aufloesung. Bruchteilsekunden (Millisekunden- / Mikrosekunden-Praezision) erfordern die laengeren Formate. Wenn Ihre Daten Sub-Sekunden-Praezision brauchen, muessen Sie Millisekunden (13 Ziffern), Mikrosekunden (16) oder Nanosekunden (19) speichern. Nur die Integer-Sekunden zu speichern wirft die Praezision weg.

Ist JavaScript new Date().valueOf() dasselbe wie Date.now()?
Ja. Beide geben Unix-Millisekunden zurueck. Date.now() ist die moderne, bevorzugte Form; new Date().valueOf() ist aelter, langsamer (es allokiert ein Date-Objekt), produziert aber dieselbe Zahl.

Verwandt

• Millisekunden zu Datum konvertieren - das Aktions-Tool fuer 13-stellige Zahlen; multiplizieren Sie zuerst 10-stellige Sekunden mit 1000.
• Aktuelle Unix-Millisekunden bekommen - Live-Ticker; nuetzlich zum Vergleichen Ihrer Zahl mit "jetzt".
• Unix-Zeitstempel erklaert - die Format-Referenz: Epoche, ISO 8601, RFC 2822, UTC vs lokale Zeit, die drei haeufigen Zeitstempel-Fallen.
• MD5 vs SHA-256 wann zu hashen - wenn Ihre "Zahl" sich als 32 oder 64 Hex-Zeichen herausstellt, ist es ein Hash, kein Zeitstempel.
• CSV vs JSON Datenformate - das Format, in dem Ihr Zeitstempel ankam, gibt oft einen Hinweis darauf, wie er codiert wurde (ISO 8601 in CSV, Millisekunden in JSON).