Unix-Timestamp erklärt: So zählen Computer die Zeit

Wer mit Logdateien, Datenbanken, APIs oder JavaScript arbeitet, stößt früher oder später auf zehn- oder dreizehnstellige Zahlen wie 1791460800. Das ist ein Unix-Timestamp (auch Epoch-Zeit oder POSIX-Zeit): die Anzahl der Sekunden, die seit dem 1. Januar 1970, 00:00:00 UTC vergangen sind. Dieser Startpunkt heißt Unix-Epoche. Der Vorteil: Ein einziger Zahlenwert beschreibt einen Zeitpunkt eindeutig – ohne Datumsformat, ohne Zeitzone, ohne Sommerzeit. Rechnen ist trivial: Differenz zweier Zeitstempel geteilt durch 86.400 ergibt die Tage dazwischen.

Beispiele

Mit dem Unix-Timestamp-Umrechner wandeln Sie Werte in beide Richtungen um und sehen sofort UTC und Ortszeit.

Sekunden oder Millisekunden?

Der häufigste Fehler im Alltag: Sekunden und Millisekunden verwechseln.

Wer einen Millisekundenwert als Sekunden interpretiert, landet im Jahr 58.000 und später. Umgekehrt ergibt ein Sekundenwert als Millisekunden ein Datum im Januar 1970. Beide Symptome sind eindeutige Hinweise.

// JavaScript: Sekunden ↔ Millisekunden
const sek = Math.floor(Date.now() / 1000);
const datum = new Date(1791460800 * 1000);

# Linux/macOS: aktueller Timestamp und Rückwandlung
date +%s
date -u -d @1791460800        # GNU/Linux
date -u -r 1791460800         # macOS

Zeitzonen und Sommerzeit

Ein Timestamp kennt keine Zeitzone – er beschreibt überall auf der Welt denselben Moment. Fehler entstehen erst bei der Umwandlung in eine lesbare Uhrzeit:

• Speichern in UTC: Speichern Sie Zeitpunkte als Timestamp oder als ISO-8601-String mit Z bzw. Offset (2026-10-08T12:00:00Z).
• Anzeige in Ortszeit: Erst im Frontend oder Bericht in Europe/Berlin umrechnen. Die IANA-Zone kennt die Sommerzeitregeln; ein fester Offset +01:00 ist im Sommer falsch.
• Lokale Zeit ohne Zone wie 2026-10-25 02:30 ist in Deutschland mehrdeutig: An diesem Tag gibt es 2:30 Uhr zweimal (erst MESZ, dann MEZ).

Wie Zeitzonen und Umstellungstermine zusammenhängen, erklärt der Ratgeber Zeitzonen erklärt.

Schaltsekunden: Unix-Zeit ignoriert sie. Jeder Tag hat exakt 86.400 Sekunden. Für Anwendungen jenseits der Wissenschaft spielt das keine Rolle.

Das Jahr-2038-Problem

Viele ältere Systeme speichern den Timestamp als vorzeichenbehaftete 32-Bit-Ganzzahl. Deren Maximum ist 2.147.483.647 – erreicht am 19. Januar 2038 um 03:14:07 UTC. Eine Sekunde später springt der Wert ins Negative und wird als 13. Dezember 1901 interpretiert.

Betroffen sein können:

• eingebettete Systeme (Industriesteuerungen, Router, Fahrzeuge) mit langer Lebensdauer
• alte Dateiformate und Datenbankspalten (z. B. MySQL-Typ TIMESTAMP mit Obergrenze 2038)
• Software, die heute schon Daten nach 2038 verarbeitet, etwa 30-jährige Kredite oder Zertifikate

Moderne Betriebssysteme und Sprachen verwenden 64-Bit-Zeitstempel; damit reicht der Wertebereich für Milliarden Jahre. Prüfen Sie aber Datenbankschemata: Für Daten jenseits 2038 eignet sich in MySQL DATETIME oder ein BIGINT.

Cron-Syntax: Zeitpläne für Aufgaben

Zeitstempel und Cron begegnen sich oft: Cron startet Skripte nach Zeitplan, die Logs schreiben Timestamps. Ein Cron-Ausdruck hat fünf Felder:

┌──────── Minute (0–59)
│ ┌────── Stunde (0–23)
│ │ ┌──── Tag des Monats (1–31)
│ │ │ ┌── Monat (1–12)
│ │ │ │ ┌ Wochentag (0–7, 0 und 7 = Sonntag)
│ │ │ │ │
* * * * *  Befehl

Wichtige Hinweise:

• Cron läuft in der Zeitzone des Servers – oft UTC. Ein Job „um 8 Uhr“ läuft dann um 9 oder 10 Uhr deutscher Zeit.
• Jobs zwischen 2:00 und 3:00 Uhr können bei der Zeitumstellung ausfallen oder doppelt laufen, wenn der Server in Ortszeit arbeitet.
• Sind Tag des Monats und Wochentag gesetzt, startet klassischer Cron den Job, wenn eines von beiden zutrifft.

Den passenden Ausdruck stellen Sie im Cron-Generator zusammen und sehen die nächsten Ausführungszeiten.

Praxis-Tipps

• Einheit im Feldnamen: created_at_ms oder expires_s verhindert Verwechslungen.
• Ganzzahlen statt Gleitkomma für Timestamps verwenden; JavaScript-Zahlen sind bis 2^53 − 1 exakt, das reicht für Millisekunden bis weit in die Zukunft.
• Differenzen rechnen: (t2 − t1) / 86400 ergibt Tage, aber bei Kalendertagen über eine Zeitumstellung hinweg rechnen Sie besser mit Datumsbibliotheken. Tage zwischen zwei Kalenderdaten zeigt der Rechner Tage zwischen zwei Daten.
• APIs dokumentieren: In JSON-Antworten klar angeben, ob Sekunden, Millisekunden oder ISO-Strings verwendet werden; siehe JSON Grundlagen.

Timestamps in Datenbanken und Logs

• MySQL/MariaDB: FROM_UNIXTIME(1791460800) wandelt in ein Datum, UNIX_TIMESTAMP() liefert den aktuellen Wert. Die Ausgabe hängt von der Zeitzone der Sitzung ab.
• PostgreSQL: to_timestamp(1791460800) liefert einen timestamptz; extract(epoch from now()) den aktuellen Wert inklusive Nachkommastellen.
• Excel und Google Sheets: Ein Sekunden-Timestamp in Zelle A1 wird mit =A1/86400+DATUM(1970;1;1) zu einem Datum in UTC; für deutsche Zeit addieren Sie 1/24 bzw. 2/24.
• Logdateien: Webserver schreiben oft lokale Zeit mit Offset (08/Oct/2026:14:00:00 +0200). Beim Zusammenführen von Logs mehrerer Server immer in UTC umrechnen.

Checkliste

• 10 Stellen = Sekunden, 13 Stellen = Millisekunden.
• Intern in UTC speichern, erst bei der Anzeige in Ortszeit umrechnen.
• IANA-Zonen statt fester Offsets.
• 32-Bit-Felder und TIMESTAMP-Spalten auf 2038 prüfen.
• Cron-Zeitzone des Servers kennen, Zeitumstellung beachten.