JavaScript Date.now(): Unix-Timestamps holen und umwandeln
Ein Guide rund um JavaScript Date.now(): hol den aktuellen Unix-Timestamp, wandle Sekunden vs. Millisekunden um, mach aus Timestamps Date-Objekte, formatiere mit Intl und vermeide die häufigen Parsing-Fallen.
Wie JavaScript Zeit intern speichert
Jedes JavaScript-Date ist intern ein einzelner 64-Bit-Float, der Millisekunden seit der Unix-Epoch (1. Januar 1970 00:00:00 UTC) darstellt. Diese Zahl liefern Date.getTime() und Date.now(). In einem Date ist keine Zeitzone gespeichert — es ist immer ein UTC-Millisekundenzähler. Zeitzonen-Infos zählen nur beim Formatieren des Datums zur Anzeige, weshalb dasselbe Date-Objekt in Los Angeles als Montagabend und in Tokio als Dienstagmorgen erscheinen kann. Dieser Beitrag konzentriert sich auf Date.now() und das Umwandeln von Timestamps; für eine breitere Übersicht jeder Timestamp-Aufgabe in JavaScript siehe den vollständigen Referenz-Guide unten.
Den aktuellen Unix-Timestamp holen
Nutze Date.now() für Millisekunden und Math.floor(Date.now() / 1000) für Sekunden. Beide werden breit unterstützt und brauchen keine Imports. Die wichtige Benennungsgewohnheit ist, die Einheit in den Variablennamen aufzunehmen: createdAtMs, expiresAtSeconds oder unixSeconds. Einheitennamen verhindern, dass ein künftiger API-Konsument rät, was ein nacktes Timestamp-Feld bedeutet.
- Date.now() → 1700000000000 (milliseconds, 13 digits)
- Math.floor(Date.now() / 1000) → 1700000000 (seconds, 10 digits)
- +new Date() → same as Date.now() via unary coercion
- new Date().getTime() → same result, slightly more verbose
Date.now() vs. performance.now()
Date.now() ist für Wanduhr-Timestamps: Logs, API-Payloads, Datenbankfelder, Cache-Ablauf und alles, was sich an realer Kalenderzeit ausrichten muss. performance.now() ist zum Messen verstrichener Dauer innerhalb der aktuellen Seite oder des Prozesses. Es ist monoton und hochpräzise, aber kein Unix-Timestamp und ohne zusätzlichen Bezugspunkt nicht in ein echtes Datum umwandelbar.
- Nutze Date.now(), wenn der Wert gespeichert, an eine API gesendet oder als Datum gezeigt wird
- Nutze performance.now(), um zu messen, wie lange Rendering, Parsing oder eine Anfrage gedauert haben
- Speichere performance.now() nicht als Ereigniszeit in einer Datenbank
- Subtrahiere keine zwei Date.now()-Werte für sicherheitsrelevante Zeitmessung; Systemuhr-Änderungen können sie beeinflussen
Einen Timestamp in ein Date umwandeln
Der Date-Konstruktor akzeptiert Millisekunden. Wenn dein Timestamp in Sekunden (10 Stellen) ist, multipliziere vor der Übergabe mit 1000. Das zu vergessen ist der häufigste JavaScript-Timestamp-Fehler. Ein schneller Test ist die Stellenzahl: aktuelle Unix-Sekunden haben 10 Stellen, aktuelle Unix-Millisekunden 13 Stellen, und ein Date-Konstruktoraufruf sollte die 13-stellige Millisekundenform erhalten.
- new Date(1700000000 * 1000) → Tue Nov 14 2023 22:13:20 UTC ✓ correct
- new Date(1700000000) → Tue Jan 20 1970 16:13:20 UTC ✗ missing × 1000
- new Date(1700000000 * 1000).toISOString() → '2023-11-14T22:13:20.000Z'
- new Date(1700000000 * 1000).toUTCString() → 'Tue, 14 Nov 2023 22:13:20 GMT'
Zeitzonenbewusstes Formatieren mit Intl
Nutze Intl.DateTimeFormat für locale- und zeitzonenbewusste Ausgabe. Es behandelt Sommerzeit automatisch und braucht keine externen Bibliotheken. Es ist der sicherste eingebaute Weg für Dashboards, Admin-Tools, Statusseiten und nutzerseitige Timestamps, weil du sowohl Locale als auch IANA-Zeitzone explizit wählen kannst.
- new Intl.DateTimeFormat('en-US', { timeZone: 'America/New_York', dateStyle: 'full', timeStyle: 'long' }).format(date)
- date.toLocaleString('en-GB', { timeZone: 'Europe/London', hour12: false })
- date.toLocaleString('zh-CN', { timeZone: 'Asia/Shanghai' })
- new Intl.DateTimeFormat('en-CA', { timeZone: tz }).formatToParts(date) → array of {type, value} for custom layouts
Datums-Strings sicher parsen
Beim Parsen wird JavaScript überraschend. ISO-Strings mit explizitem Z oder Offset sind sicher, weil sie einen exakten Moment identifizieren. Nackte Daten und informelle Strings sind leichter lesbar, hängen aber oft von Browser-Regeln oder der Runtime-Zeitzone ab. Bevorzuge für API-Verträge ISO-8601-Strings mit Zeitzone oder numerische Unix-Timestamps mit der Einheit im Feldnamen.
- Safe: new Date('2026-05-19T14:30:00Z') — explicit UTC
- Safe: new Date('2026-05-19T10:30:00-04:00') — explicit offset
- Risky: new Date('05/19/2026') — locale-dependent and ambiguous
- Risky: new Date('2026-05-19 10:30') — not a strict ISO timestamp in all runtimes
Häufige JavaScript-Timestamp-Fehler
- new Date(1700000000) statt new Date(1700000000 * 1000) — landet in 1970, nicht 2023
- getMonth() liefert 0–11, nicht 1–12 — nutze bei der Anzeige immer date.getMonth() + 1
- new Date('2024-01-01') wird als UTC-Mitternacht geparst; new Date('2024/01/01') als lokale Mitternacht
- 86400000 ms für „morgen“ zu addieren bricht bei Sommerzeit-Umstellungen — nutze setDate(d.getDate() + 1)
- Date-Objekte mit === zu vergleichen scheitert immer — vergleiche stattdessen ihre .getTime()-Werte
Empfohlene JavaScript-Timestamp-Checkliste
Das einfachste Produktionsmuster ist, einen einzigen kanonischen Moment zu speichern und ihn nur am Rand zu formatieren. Halte Timestamps in UTC, nimm Einheiten in Namen auf und wandle erst in der UI- oder Reporting-Schicht in eine lesbare Zeitzone um.
- Nutze Unix-Millisekunden für reinen Browser-State und JavaScript-Date-Konstruktion
- Nutze Unix-Sekunden beim Aufruf von APIs, die Unix-Zeit in Sekunden dokumentieren
- Nutze ISO 8601 mit Z oder explizitem Offset, wenn Menschen Payloads prüfen könnten
- Nutze Intl.DateTimeFormat mit einer expliziten timeZone zur Anzeige
- Füge Tests rund um Sommerzeit-Grenzen hinzu, wenn lokale Kalenderdaten wichtig sind
FAQ zu JavaScript-Timestamps
- Liefert Date.now() Sekunden oder Millisekunden?
- Date.now() liefert Millisekunden seit dem 1. Januar 1970 00:00:00 UTC. Teile durch 1000 und nutze Math.floor(), wenn eine API Unix-Sekunden erwartet.
- Warum zeigt new Date(1700000000) 1970?
- Der Date-Konstruktor erwartet Millisekunden. 1700000000 ist ein Sekunden-Timestamp, also liest JavaScript ihn als nur 1,7 Milliarden Millisekunden nach der Epoch. Nutze new Date(1700000000 * 1000).
- Speichert ein JavaScript-Date eine Zeitzone?
- Nein. Ein Date speichert einen UTC-Millisekundenzähler. Die Zeitzone wird nur beim Formatieren mit Methoden wie toString(), toLocaleString() oder Intl.DateTimeFormat angewandt.
- Wie wandle ich einen Unix-Timestamp in ein JavaScript-Date um?
- Übergib Millisekunden an den Konstruktor: new Date(seconds * 1000) für einen 10-stelligen Sekundenwert oder new Date(ms) für einen 13-stelligen Millisekundenwert. Das × 1000 zu vergessen ist der Grund, warum ein 2023-Timestamp als 1970 erscheinen kann.