Wie benutzt du dieses Tool?
- Gib einen Unix-Timestamp in Sekunden in das Eingabefeld ein.
- Das Ergebnis in Millisekunden erscheint sofort — kein Klick nötig.
- Kopiere das Ergebnis über den Copy-Button in die Zwischenablage.
Was macht der Konverter?
Ein Unix-Timestamp zählt Sekunden seit dem 1. Januar 1970 00:00:00 UTC — der sogenannten Epoch. POSIX-Systeme, C und Python verwenden Sekunden (10 Stellen). JavaScript, Java und Kafka verwenden Millisekunden (13 Stellen). Der Konverter rechnet zwischen beiden Darstellungen um: Sekunden × 1000 = Millisekunden, Millisekunden ÷ 1000 = Sekunden.
Die Umrechnung klingt trivial, ist aber eine der häufigsten Fehlerquellen beim Datenaustausch zwischen Backend und Frontend. Wer einen 10-stelligen Timestamp in new Date() steckt, landet im Januar 1970 statt im aktuellen Jahr.
Was ist die Umrechnungsformel?
Die Formel ist exakt, ohne Rundung:
Sekunden (s) × 1000 = Millisekunden (ms)
Millisekunden (ms) ÷ 1000 = Sekunden (s)
Beispiel: Der Unix-Timestamp 1745230000 (Sekunden) entspricht 1745230000000 (Millisekunden). In JavaScript: new Date(1745230000000) ergibt den 21. April 2025, 12:26:40 UTC.
Welche Anwendungsbeispiele gibt es?
Gängige Werte und ihre Umrechnung:
| Sekunden (POSIX) | Millisekunden (JS) | Bedeutung |
|---|---|---|
| 0 | 0 | Epoch: 1. Jan 1970 00:00:00 UTC |
| 86.400 | 86.400.000 | Exakt ein Tag (24 × 60 × 60) |
| 604.800 | 604.800.000 | Exakt eine Woche |
| 2.629.746 | 2.629.746.000 | Durchschnittlicher Monat (30,44 Tage) |
| 31.556.952 | 31.556.952.000 | Durchschnittliches Jahr (365,2425 Tage) |
| 1.745.230.000 | 1.745.230.000.000 | April 2025 (Referenzwert) |
| 2.147.483.647 | 2.147.483.647.000 | Y2038-Grenze (32-Bit-Maximum) |
Merke: Ein Tag hat exakt 86.400 Sekunden, eine Woche 604.800. Diese Werte sind konstant, weil Unix-Timestamps keine Schaltsekunden zählen.
Welche Einsatzgebiete gibt es?
Log-Analyse und Debugging: Server-Logs, Kafka-Events und Datenbank-Einträge speichern Zeitpunkte als Unix-Timestamps. Beim Vergleich zwischen Python-Backend (Sekunden) und JavaScript-Frontend (Millisekunden) ist der Faktor 1000 entscheidend. Ohne korrekte Umrechnung zeigen Dashboards Zeitpunkte im Jahr 1970 statt im aktuellen Monat.
API-Entwicklung: REST-APIs und Webhooks transportieren Timestamps in unterschiedlichen Präzisionen. Stripe verwendet Sekunden, Discord Millisekunden, InfluxDB Nanosekunden. Wer APIs integriert, braucht die Umrechnung regelmäßig — nicht als Kopfrechnung, sondern als verlässliches Werkzeug.
Daten-Migration: Beim Import von CSV- oder JSON-Daten in eine neue Datenbank muss die Timestamp-Präzision stimmen. PostgreSQL erwartet Mikrosekunden, MongoDB Millisekunden. Falsche Umrechnung führt zu kaputten Zeitreihen, die erst Wochen später in Reports auffallen.
Y2038-Assessment: Unternehmen mit Legacy-Systemen prüfen aktuell, welche Komponenten noch 32-Bit-Timestamps verwenden. Der Maximalwert 2.147.483.647 (19. Januar 2038, 03:14:07 UTC) ist die harte Grenze. Wer Timestamps über diesen Wert hinaus speichern muss, braucht 64-Bit-Integer.
Präzisions-Varianten im Überblick
Neben Sekunden und Millisekunden existieren zwei weitere Präzisionsstufen:
| Einheit | Stellen | Beispiel | Verbreitung |
|---|---|---|---|
| Sekunden (s) | 10 | 1745230000 | POSIX, C, Python, Unix |
| Millisekunden (ms) | 13 | 1745230000000 | JavaScript, Java, Kafka |
| Mikrosekunden (µs) | 16 | 1745230000000000 | PostgreSQL, Python time.time_ns() |
| Nanosekunden (ns) | 19 | 1745230000000000000 | Go, Rust, Temporal.Instant |
Die Stellenzahl ist das zuverlässigste Erkennungsmerkmal: 10 Stellen = Sekunden, 13 Stellen = Millisekunden, 16 Stellen = Mikrosekunden, 19 Stellen = Nanosekunden.
Das Y2038-Problem
Am 19. Januar 2038 um 03:14:07 UTC erreicht der Wert 2147483647 das Maximum eines 32-Bit-Signed-Integer. Systeme, die Timestamps in 32 Bit speichern, interpretieren den nächsten Wert als −2.147.483.648 — ein Sprung zurück ins Jahr 1901.
64-Bit-Timestamps lösen das Problem: Sie reichen bis ca. Jahr 292 Milliarden. Alle modernen Betriebssysteme und Programmiersprachen verwenden 64 Bit. Gefährdet sind Embedded-Systeme, alte Datenbank-Schemata und Firmware, die seit Jahrzehnten nicht aktualisiert wurde.
Die Temporal-API (ES2026, seit März 2026 Stage 4) verwendet intern Nanosekunden als BigInt — das Y2038-Problem existiert dort nicht.
Häufige Fragen
Die Antworten auf die wichtigsten Fragen findest du oben im FAQ-Block — sie werden als strukturiertes JSON-LD (FAQPage) für Suchmaschinen ausgegeben.
Welche Zeit-Tools sind verwandt?
Weitere Tools aus dem Konverter-Ökosystem, die zum Thema passen:
- JSON Formatter — API-Responses mit Timestamps lesbar formatieren und Syntaxfehler erkennen.
- Zeichenzähler — Stellenzahl von Timestamps prüfen, um Sekunden von Millisekunden zu unterscheiden.
- Text-Diff — Zwei Log-Dateien mit Timestamps vergleichen und Unterschiede hervorheben.
Zuletzt aktualisiert: