Unix-Zeitstempel erklärt: Umrechnung und häufige Fallstricke

Ein Unix-Zeitstempel ist eines der einfachsten und zugleich am meisten missverstandenen Konzepte in der Programmierung. Es ist die Anzahl der Sekunden, die seit dem 1. Januar 1970, 00:00:00 UTC vergangen sind — ein Moment, der als Unix-Epoch bekannt ist. Trotz seiner Einfachheit sind Zeitstempel eine Quelle von Fehlern im Zusammenhang mit Zeitzonen, Präzision und Überlauf.

Was ist die Unix-Epoch?

Die Unix-Epoch — 1. Januar 1970, 00:00:00 UTC — wurde als Startpunkt für Unix-Zeit gewählt. Jeder Zeitstempel wird relativ zu diesem Moment gemessen:

Negative Zeitstempel stellen Daten vor der Epoch dar. Zum Beispiel ist -86400 der 31. Dezember 1969.

Rechnen Sie Zeitstempel sofort mit unserem Zeitstempel-Konverter um.

Sekunden vs. Millisekunden

Dies ist die häufigste Quelle von Verwirrung. Verschiedene Systeme verwenden unterschiedliche Präzisionen:

Faustregel: Wenn die Zahl 13 Stellen hat, sind es Millisekunden. Bei 10 Stellen sind es Sekunden.

// JavaScript gibt Millisekunden zurück
const nowMs = Date.now();          // 1700000000000
const nowSec = Math.floor(nowMs / 1000);  // 1700000000

Zeitzonen-Behandlung

Unix-Zeitstempel sind immer UTC. Sie enthalten keine Zeitzoneninformation. Das ist tatsächlich ein Vorteil — es bietet einen universellen Referenzpunkt.

Die Verwirrung entsteht bei der Umrechnung von Zeitstempeln in lesbare Daten:

const ts = 1700000000;
const date = new Date(ts * 1000);

date.toUTCString();      // "Tue, 14 Nov 2023 22:13:20 GMT"
date.toLocaleString();    // Abhängig von der lokalen Zeitzone des Benutzers
date.toISOString();       // "2023-11-14T22:13:20.000Z"

Best Practice: Zeitstempel in UTC speichern und übertragen. Nur auf der Darstellungsebene in lokale Zeit umrechnen, so nah am Benutzer wie möglich.

Das Jahr-2038-Problem

Traditionelle Unix-Systeme speichern Zeitstempel als vorzeichenbehaftete 32-Bit-Ganzzahl. Der Maximalwert ist 2.147.483.647, was dem 19. Januar 2038, 03:14:07 UTC entspricht.

Nach diesem Moment laufen 32-Bit-Zeitstempel in negative Werte über und springen zurück zum 13. Dezember 1901. Dies ist analog zum Y2K-Bug.

Aktueller Stand:

• Die meisten modernen Systeme verwenden 64-Bit-Zeitstempel (ausreichend bis zum Jahr 292 Milliarden)
• Der Linux-Kernel ist seit Version 5.6 (2020) 64-Bit-Zeitstempel-kompatibel
• Eingebettete Systeme und Legacy-Datenbanken sind weiterhin gefährdet
• Wenn Sie Software bauen, die Daten nach 2038 verarbeitet, überprüfen Sie Ihre Zeitstempel-Speicherung

Umrechnung in verschiedenen Sprachen

JavaScript

// Aktueller Zeitstempel (Sekunden)
const now = Math.floor(Date.now() / 1000);

// Zeitstempel zu Date
const date = new Date(1700000000 * 1000);

// Date zu Zeitstempel
const ts = Math.floor(new Date('2023-11-14').getTime() / 1000);

Python

import time, datetime

# Aktueller Zeitstempel
now = int(time.time())

# Zeitstempel zu datetime
dt = datetime.datetime.fromtimestamp(1700000000, tz=datetime.timezone.utc)

# Datetime zu Zeitstempel
ts = int(dt.timestamp())

SQL (PostgreSQL)

-- Aktueller Zeitstempel
SELECT EXTRACT(EPOCH FROM NOW());

-- Zeitstempel zu Datum
SELECT TO_TIMESTAMP(1700000000);

-- Datum zu Zeitstempel
SELECT EXTRACT(EPOCH FROM '2023-11-14'::timestamp);

Häufige Fallstricke

1. Sekunden und Millisekunden verwechseln

Wenn ein Datum als Januar 1970 angezeigt wird, haben Sie wahrscheinlich Sekunden übergeben, wo Millisekunden erwartet wurden (oder umgekehrt). Prüfen Sie immer, welche Präzision die API erwartet.

2. Zeitzonen in Datumszeichenketten ignorieren

Das Parsen von "2023-11-14" ohne Zeitzone erzeugt das Datum in der lokalen Zeitzone, die je nach Serverstandort variiert. Schließen Sie immer die Zeitzone ein: "2023-11-14T00:00:00Z".

3. Gleitkomma-Präzision

Beim Speichern von Zeitstempeln als Gleitkommazahlen können Sie Präzision jenseits von Millisekunden verlieren. Für Mikrosekunden- oder Nanosekunden-Präzision verwenden Sie Ganzzahlen mit dem entsprechenden Multiplikator.

4. Schaltsekunden

Unix-Zeitstempel berücksichtigen keine Schaltsekunden. Ein Unix-Tag ist immer genau 86.400 Sekunden, auch wenn tatsächliche UTC-Tage gelegentlich 86.401 Sekunden haben. Für die meisten Anwendungen ist dies irrelevant. Für wissenschaftliche oder Satellitenanwendungen verwenden Sie stattdessen TAI (Internationale Atomzeit).

ISO 8601: Die menschenlesbare Alternative

Während Zeitstempel großartig für Berechnungen sind, ist ISO 8601 der Standard für menschenlesbare Datumsdarstellung:

2023-11-14T22:13:20Z          # UTC
2023-11-14T17:13:20-05:00     # Eastern Time
2023-11-14                     # Nur Datum

Die meisten APIs sollten ISO-8601-Zeichenketten akzeptieren und zurückgeben. Verwenden Sie Zeitstempel intern für Berechnungen und Speicherung.

FAQ

Warum beginnt die Unix-Zeit am 1. Januar 1970?

Das Datum wurde willkürlich gewählt, als Unix in den frühen 1970er Jahren bei Bell Labs entwickelt wurde. Ein ausreichend aktuelles Datum war nötig, um keine Bits für weit zurückliegende Daten zu verschwenden. Da 32-Bit-Ganzzahlen etwa 68 Jahre in jede Richtung speichern können, deckte der Start bei 1970 Daten von 1901 bis 2038 ab.

Sollte ich Daten als Zeitstempel oder formatierte Zeichenketten in meiner Datenbank speichern?

Speichern Sie Daten als Zeitstempel (Ganzzahl oder native Datetime-Typen) für effizientes Sortieren, Vergleichen und Rechnen. Formatierte Zeichenketten sind schwerer abzufragen und korrekt zu sortieren. Die meisten Datenbanken haben native Datetime-Typen, die dies gut handhaben. Reservieren Sie die Zeichenkettenformatierung für die Anzeige und API-Antworten.

Verwandte Ressourcen

• Zeitstempel-Konverter — Zwischen Unix-Zeitstempeln und lesbaren Daten umrechnen
• JSON-Formatierung Best Practices — Umgang mit Daten in JSON-Antworten
• UUID-Leitfaden — Ein weiteres gängiges Identifikatorformat mit zeitbasierten Varianten