Unix-Timestamps: die vier Fallen, die Ihre Daten brechen

Ein Unix-Timestamp ist nur eine Zahl: Sekunden seit 1970-01-01 UTC. Einfach — und doch verursachen Timestamps mehr Datums-Bugs als jedes andere Format. Vier Fallen erklären die meisten.

1. Sekunden vs. Millisekunden

JavaScripts Date.now() liefert Millisekunden; klassische Unix-Zeit und die meisten Backend-Logs nutzen Sekunden. Eine 10-stellige Zahl ist Sekunden, 13-stellig Millisekunden. Vermischt wird 2026 zu einem Datum im Jahr 53.000 — oder 1970.

2. UTC vs. lokale Zeit

Der Timestamp selbst hat keine Zeitzone — er ist überall derselbe Moment. Bugs entstehen, wenn Code mit der Serverzeit statt der Nutzerzeit konvertiert, oder wenn ein String wie 2026-09-01 08:00 ohne Angabe der Zone geparst wird.

3. Sommerzeit-Sprünge

Zonen mit Sommerzeit springen zweimal im Jahr um eine Stunde. Ein Meeting, das als 09:00 Ortszeit im Sommer und Winter gespeichert wird, ist zwei verschiedene UTC-Momente; UTC speichern und erst bei der Anzeige konvertieren beseitigt diese ganze Bug-Klasse.

4. Locale-abhängiges Parsing

Strings wie 03/04/2026 bedeuten im einen Land den 4. März, im anderen den 3. April. Datums-Parsing braucht ein explizites Format — niemals raten.

Die Arbeitsregeln: UTC speichern, nur für die Anzeige konvertieren, Formate immer benennen. Um einen Timestamp oder Datumsstring zu prüfen: Timestamp-Konverter oder Weltuhren im Vergleich — beide laufen lokal im Browser.