Epochen-Timestamps erklärt: Wie Unix-Zeit funktioniert (und warum sie bricht)

Ein Epochen-Timestamp – auch Unix-Zeit oder POSIX-Zeit genannt – ist die Anzahl der Sekunden, die seit dem 1. Januar 1970 00:00:00 UTC vergangen sind, ohne Schaltsekunden. Es ist eine einfache Ganzzahl, die einen präzisen Zeitpunkt darstellt, unabhängig von Zeitzonen und Kalendersystemen. Diese Einfachheit macht es zum Standard, wie Computer Zeitinformationen austauschen, aber es hat auch bekannte Einschränkungen und Fallstricke, die jeder Entwickler verstehen sollte.

Wie Unix-Zeit funktioniert

Die Unix-Zeit zählt ab der Epoche vorwärts. Ein Tag entspricht 86.400 Sekunden (24 × 60 × 60). Der Timestamp erhöht sich unabhängig von Zeitzone, Sommerzeit oder Schaltjahren um genau eine pro Sekunde.

Timestamp 0        → 1970-01-01 00:00:00 UTC
Timestamp 86400    → 1970-01-02 00:00:00 UTC
Timestamp 1000000  → 1970-01-12 13:46:40 UTC
Timestamp 1782000000 → 2026-06-17 00:00:00 UTC

// JavaScript — aktuellen Unix-Timestamp abrufen
const nowInSeconds = Math.floor(Date.now() / 1000);
console.log(nowInSeconds);

// Timestamp in Datum umwandeln
const date = new Date(nowInSeconds * 1000);
console.log(date.toISOString());

// PHP — aktuellen Unix-Timestamp abrufen
echo time();             // Sekunden seit Epoche
echo microtime(true);    // Sekunden mit Mikrosekunden-Genauigkeit

// Timestamp in Datum umwandeln
echo date('Y-m-d H:i:s', 1782000000);

Sekunden vs. Millisekunden: Eine häufige Fehlerquelle

Einer der häufigsten timestamp-bezogenen Fehler ist die Verwechslung von Sekunden mit Millisekunden. JavaScripts Date.now() gibt Millisekunden zurück, während PHPs time() Sekunden zurückgibt. Viele Datenbanken speichern Timestamps in Sekunden, und viele APIs verwenden Millisekunden.

// ❌ Falsch — Millisekunden als Sekunden behandeln
const timestamp = 1782000000; // dies ist in Sekunden
const wrongDate = new Date(timestamp); // interpretiert als Millisekunden
console.log(wrongDate.toISOString()); // 1970-01-21 — völlig falsch

// ✅ Richtig — mit 1000 multiplizieren
const correctDate = new Date(timestamp * 1000);
console.log(correctDate.toISOString()); // 2026-06-17

import time
from datetime import datetime

# ❌ Falsch — vergessen, Millisekunden zu dividieren
millis = 1782000000000
wrong = datetime.fromtimestamp(millis)  # ValueError: year out of range

# ✅ Richtig
correct = datetime.fromtimestamp(millis / 1000)
print(correct)  # 2026-06-17 00:00:00

Das Jahr-2038-Problem

Die Unix-Zeit verwendet eine vorzeichenbehaftete 32-Bit-Ganzzahl, die einen Maximalwert von 2.147.483.647 hat. Am 19. Januar 2038 um 03:14:07 UTC erreicht der Timestamp diese Grenze. Eine Sekunde später läuft eine 32-Bit-vorzeichenbehaftete Ganzzahl auf −2.147.483.648 über, was dem 13. Dezember 1901 entspricht.

2.147.483.647 → 2038-01-19 03:14:07 UTC (max. 32-Bit vorzeichenbehaftet)
2.147.483.648 → läuft auf negativ über (Unterlauf)

Systeme, die noch für Y2038 anfällig sind:

• Eingebettete Systeme (Router, IoT-Geräte, Autofirmware)
• Legacy-Datenbanken, die Timestamps als INT(10) speichern
• Alte Linux-Kernel auf 32-Bit-Architekturen
• Dateisysteme mit 32-Bit-Timestamps
• Ältere PHP-Versionen auf 32-Bit-Builds

So überprüfen Sie, ob ein System Y2038-sicher ist:

# Linux — prüfen, ob time_t 64-Bit ist
getconf LONG_BIT
# 64 → sicher
# 32 → Kernel- und libc-Version prüfen

# PHP — Ganzzahlgröße überprüfen
php -r 'echo PHP_INT_SIZE;'
# 8 → sicher (64-Bit)
# 4 → anfällig (32-Bit)

Moderne Systeme mit 64-Bit time_t können Timestamps bis zu etwa 292 Milliarden Jahre in die Zukunft darstellen, womit Y2038 kein Problem mehr darstellt. Die meisten Produktionsserver laufen bereits auf 64-Bit-Betriebssystemen, aber eingebettete und Legacy-Systeme bleiben gefährdet.

Schaltsekunden: Die versteckte Komplexität

Die Unix-Zeit ignoriert Schaltsekunden. Per Definition hat jeder Tag genau 86.400 Sekunden. Aber die astronomische Zeit (UT1) benötigt gelegentlich eine zusätzliche Sekunde – eine Schaltsekunde – um mit der Erdrotation synchron zu bleiben. Wenn eine Schaltsekunde auftritt, wiederholt die Unix-Zeit dieselbe Sekunde:

2016-12-31 23:59:59 UTC
2016-12-31 23:59:60 UTC  ← Schaltsekunde (nicht in Unix-Zeit darstellbar)
2017-01-01 00:00:00 UTC

Die meisten Anwendungen ignorieren Schaltsekunden vollständig, da sie unvorhersehbar auftreten (typischerweise einmal alle 1-3 Jahre) und ihre Handhabung erhebliche Komplexität mit sich bringt. Systeme, die präzise Zeitmessung erfordern – wie Finanzhandelsplattformen und astronomische Observatorien – verwenden TAI (Internationale Atomzeit) oder GPS-Zeit anstelle der Unix-Zeit.

Häufige Fallstricke

Fallstrick 1: Die falsche Einheit verwenden

// API gibt Timestamp in Sekunden zurück
const apiTimestamp = 1782000000;

// ❌ Falsch — new Date() erwartet Millisekunden
const date = new Date(apiTimestamp);

// ✅ Richtig
const date = new Date(apiTimestamp * 1000);

Fallstrick 2: Speichern als INT(10) in MySQL

-- ❌ Falsch — INT(10) läuft bei 2,1 Milliarden über (2038)
CREATE TABLE events (
    created_at INT(10) NOT NULL
);

-- ✅ Richtig — BIGINT oder TIMESTAMP verwenden
CREATE TABLE events (
    created_at BIGINT NOT NULL,       -- 64-Bit, sicher
    created_at2 TIMESTAMP NOT NULL     -- MySQL übernimmt die Konvertierung
);

Fallstrick 3: Annahme, dass die lokale Zeit die Standardeinstellung ist

// ❌ Falsch — date() verwendet die Standardzeitzone des Servers
echo date('Y-m-d H:i:s', $timestamp);

// ✅ Richtig — explizit UTC angeben
echo gmdate('Y-m-d H:i:s', $timestamp);
echo date('Y-m-d H:i:s', $timestamp); // wenn Standard-TZ auf UTC gesetzt ist

Fallstrick 4: Ganzzahlüberlauf in JavaScript

JavaScript-Zahlen sind 64-Bit-Gleitkommazahlen, aber bitweise Operationen behandeln sie als 32-Bit-vorzeichenbehaftete Ganzzahlen. Dies kann selbst in modernen Browsern zu unerwarteten Y2038-ähnlichen Fehlern führen.

// JavaScript-Bitoperation behandelt als 32-Bit
const timestamp = 2500000000; // jenseits des 32-Bit-vorzeichenbehafteten Maximums
const shifted = timestamp << 1; // ❌ Überlauf!
console.log(shifted); // -1794967296 (überlaufen)

Epochen-Umrechnungstool

Das Epoch / Unix Timestamp Converter-Tool auf Help2Code bietet eine Live-Anzeige des aktuellen Timestamps in Sekunden und Millisekunden, bidirektionale Konvertierung zwischen Epochenwerten und lesbaren Daten sowie Unterstützung für lokale und UTC-Zeitzonen. Verwenden Sie es, um Timestamp-Probleme zu debuggen, Timestamps für Tests zu generieren oder API-Antworten zu überprüfen. Der Timezone Converter ist ebenfalls nützlich, um zu überprüfen, wie Epochen-Timestamps auf verschiedene Zeitzonen abgebildet werden.

Fazit

Epochen-Timestamps sind eine einfache und universelle Möglichkeit, Zeitpunkte darzustellen, aber sie bringen einige kritische Einschränkungen mit sich: Überprüfen Sie immer, ob Sie mit Sekunden oder Millisekunden arbeiten, verwenden Sie 64-Bit-Speicher, um das Y2038-Problem zu vermeiden, und gehen Sie niemals davon aus, dass die Standardzeitzone Ihrer Absicht entspricht. Verwenden Sie den Epoch Converter für schnelle Umrechnungen und beachten Sie die oben genannten Richtlinien beim Umgang mit Timestamps im Produktionscode.