Unix-Zeitstempel: Sekunden/Millisekunden/Mikrosekunden-Konvertierung und Zeitzonen-Best-Practices

Unix-Zeitstempel stellen Zeit als „verstrichene Zeitspanne seit der Unix-Epoche (1. Januar 1970, 00:00:00 UTC)” dar. Die meisten Webserver und Datenbanksysteme nutzen diese Darstellung intern. Dieser Leitfaden behandelt Präzisionsunterschiede, Programmiersprachen-Implementierungen, Zeitzonen-Handling und Sommerzeit-Besonderheiten.

Ursprung und Definition des Unix-Zeitstempels

Die Unix-Epoche begann am 1. Januar 1970, 00:00:00 UTC. Der Unix-Zeitstempel 0 entspricht diesem Moment, während 1262304000 den 1. Januar 2010 00:00:00 UTC repräsentiert. Das System ignoriert standardmäßig die Auswirkungen von Schaltsekunden.

Ursprünglich als 32-Bit-Ganzzahl mit Vorzeichen gespeichert, entstand das Jahr-2038-Problem: der Maximalwert läuft am 19. Januar 2038, 03:14:07 UTC über. Moderne Systeme verwenden 64-Bit-Ganzzahlen, was die darstellbaren Zeiträume erheblich erweitert.

Zeitpräzisionsunterschiede

Einheit	Anzahl pro Sekunde	Stellen	Typische Anwendungen
Sekunden (s)	1	10	Traditionelle Unix/Linux-Systeme
Millisekunden (ms)	1.000	13	JavaScript, Java, Logging
Mikrosekunden (μs)	1.000.000	16	Verteiltes Tracing, Datenbanken
Nanosekunden (ns)	1.000.000.000	19	Go-Sprache, Performance-Analyse

Praktische Regel: 10-stellige Zeitstempel repräsentieren im Allgemeinen Sekunden, 13-stellige Millisekunden, 16-stellige Mikrosekunden und 19-stellige Nanosekunden.

JavaScript-Zeitstempel

JavaScript verwendet Millisekunden nativ. Der Date()-Konstruktor interpretiert Eingabezahlen als Millisekunden. Für Sekunden-Zeitstempel mit 1000 multiplizieren.

// Aktuellen Unix-Zeitstempel abrufen (in Millisekunden)
const timestampMs = Date.now();
console.log(timestampMs);  // Beispielausgabe: 1692268800123

// Für Sekunden-Zeitstempel: Millisekunden durch 1000 teilen und abrunden
const timestampSec = Math.floor(Date.now() / 1000);
console.log(timestampSec); // Beispielausgabe: 1692268800

// Unix-Zeitstempel zurück in Date-Objekt konvertieren
let ts = 1692268800;
let date = new Date(ts * 1000);
console.log(date.toISOString()); // "2023-08-17T16:00:00.000Z"

Python-Zeitstempel

Pythons time.time() gibt Sekunden-Unix-Zeitstempel als Fließkommazahlen zurück:

import time
from datetime import datetime, timezone

# Aktuellen Unix-Zeitstempel abrufen (Sekunden, Float)
now_sec = time.time()
print(now_sec)  # Beispielausgabe: 1692268800.123456

# Millisekunden abrufen (Integer)
now_millis = int(time.time() * 1000)
print(now_millis)  # Beispiel: 1692268800123

# Nanosekunden abrufen (Python 3.7+)
now_nanos = time.time_ns()
print(now_nanos)  # Beispiel: 1692268800123456789

# In datetime konvertieren
ts = 1692268800
dt_local = datetime.fromtimestamp(ts)
dt_utc = datetime.fromtimestamp(ts, timezone.utc)
print(dt_local.strftime("%Y-%m-%d %H:%M:%S"))  # Lokale Zeit
print(dt_utc.strftime("%Y-%m-%d %H:%M:%S"))    # UTC-Zeit

Go-Zeitstempel

Go’s time-Bibliothek bietet mehrere Präzisionsstufen:

package main

import (
    "fmt"
    "time"
)

func main() {
    // Aktuellen Unix-Zeitstempel abrufen
    sec := time.Now().Unix()        // Sekunden
    msec := time.Now().UnixMilli()  // Millisekunden (Go 1.17+)
    nsec := time.Now().UnixNano()   // Nanosekunden

    fmt.Println(sec)   // Beispiel: 1692268800
    fmt.Println(msec)  // Beispiel: 1692268800123
    fmt.Println(nsec)  // Beispiel: 1692268800123456789

    // Zeitstempel in Time-Objekt konvertieren
    t := time.Unix(sec, 0)
    fmt.Println(t.UTC())
    fmt.Println(t)
}

Häufige Fehler und Best Practices

Fehlerbeispiel: Unklare Einheiten

// ✗ Falsch: unklare Zeitstempel-Einheit
const timestamp = 1692268800;
const date = new Date(timestamp); // Fehler: als Millisekunden behandelt, zeigt 1970

// ✓ Korrekt: Einheiten klar angeben
const timestampSec = 1692268800;
const timestampMs = 1692268800000;
const dateFromSec = new Date(timestampSec * 1000);

Feldbenennungs-Best-Practice

log_entry = {
    "timestamp_ms": 1692268800123,           # Millisekunden-Ebene
    "timestamp_iso": "2023-08-17T16:00:00Z", # ISO 8601 UTC
    "event_type": "user_login",
    "user_id": 12345
}

Fallstricke beim Zeitzonen-Handling

Es gibt vier Hauptfallstricke bei der Arbeit mit Zeitzonen:

Lokale Zeit und UTC verwechseln: Unix-Zeitstempel sind immer UTC-basiert; erst bei der Anzeige in lokale Zeit konvertieren
Zeitzoneninformation nicht speichern: Erzeugt Mehrdeutigkeit; immer UTC speichern oder Offset einbeziehen
Systemübergreifende Zeitzonen-Inkonsistenzen: Alle Systeme sollten dieselbe Zeitzonen-Referenz nutzen (UTC empfohlen)
DST-Offsets manuell berechnen: Auf eingebaute Bibliotheken verlassen, nicht hartcodieren

Der empfohlene Ansatz: „Standardisiert speichern, lokalisiert anzeigen.” UTC oder Unix-Zeitstempel in Speicher- und Übertragungsphasen verwenden, um Konsistenz zu gewährleisten; bei der Anzeige gemäß der Nutzer-Zeitzone formatieren.

Sommerzeit (DST) Probleme

DST erzeugt zwei problematische Zeiträume:

Übersprungene Zeit: Wenn die Sommerzeit beginnt, springen Uhren vor. Zum Beispiel springt 02:00 direkt auf 03:00, womit 02:30 nicht existiert.
Wiederholte Zeit: Wenn die Sommerzeit endet, erscheint 01:00–01:59 zweimal, was Mehrdeutigkeit erzeugt.

Unix-Zeitstempel selbst bleiben kontinuierlich und von der Sommerzeit unbeeinflusst, aber lokale Zeitkonvertierungen erfordern sorgfältige Handhabung.

Best Practices für Logging, Datenbanken und APIs

Logging-Systeme

UTC-Zeitzone + ISO-8601-Format vereinheitlichen; Millisekunden-Zeitstempel oder Mikrosekunden-Präzision einbeziehen, wenn nötig.

Datenbanken

Native Kalendertypen mit Zeitzone bevorzugen; BIGINT für numerische Zeitstempel mit klarer Einheitsangabe in Feldnamen verwenden (z. B. *_epoch_ms).

APIs

Formate und Einheiten klar spezifizieren. Externe Schnittstellen sollten ISO 8601 verwenden (lesbar, enthält Zeitzone); interne Systeme können numerische Zeitstempel mit dokumentierten Einheiten verwenden.

Häufige Fehlerszenarien

13-stelliges Parsing scheitert: Millisekunden-Zeitstempel, die an Sekunden-erwartende Funktionen übergeben werden, verursachen Overflow. Zuerst die Einheit anhand der Stellenanzahl bestimmen.
Formatinkonsistenzen: Ungültige Datumsangaben, fehlende Zeitzonen oder DST-Umschaltpunkte verursachen Parsing-Fehler.
Zeitzonen-Offsets: Ganzzahlige Stundenabweichungen (±8h) deuten typischerweise auf Vereinheitlichungsprobleme hin. UTC intern empfohlen.
Numerischer Overflow: 32-Bit-Systeme haben die 2038-Grenze; 64-Bit-Ganzzahlen priorisieren.

Häufig gestellte Fragen

Warum der 1. Januar 1970?

Die Entwicklung des Unix-Betriebssystems begann 1970, und es war ein rundes Jahrzehnt, leicht zu merken und zu berechnen. 32-Bit-Ganzzahlen konnten Daten von 1970 bis 2038 darstellen, was damals ausreichte.

Wie erkennt man Sekunden vs. Millisekunden?

Drei Methoden: Stellenanzahl prüfen (10 Stellen = Sekunden, 13 = Millisekunden, 16 = Mikrosekunden, 19 = Nanosekunden), Verifizierungsberechnung durch Parsen und Plausibilitätsprüfung, oder Online-Konvertierungstools nutzen.

Ist das 2038-Problem noch relevant?

Moderne Systeme mit 64-Bit-Ganzzahlen haben es weitgehend gelöst. Gängige Programmiersprachen unterstützen bereits 64-Bit-Zeitstempel. Legacy-32-Bit-Systeme und eingebettete Geräte können noch Aufmerksamkeit erfordern.

Warum verursacht die Sommerzeit Probleme?

Zeitdiskontinuität durch übersprungene Stunden und Zeitwiederholung durch doppelte Stunden erzeugen Parsing-Mehrdeutigkeit. Verschiedene Systeme behandeln mehrdeutige Zeiten mit unterschiedlichen Strategien. Lösung: UTC intern verwenden, erst bei der Anzeige in lokale Zeit konvertieren.

Warum unterscheiden sich JavaScript- und Python-Zeitstempel?

JavaScripts Date.now() gibt Millisekunden zurück (13 Stellen); Pythons time.time() gibt Sekunden zurück (Fließkommazahl mit Mikrosekunden-Präzision). Die Konvertierung erfordert Division/Multiplikation durch 1000.

Aktuelle Trends und Ausblick

Höhere Präzision: Finanzhandel, IoT und Echtzeitsysteme fordern Nanosekunden-Genauigkeit
Verteilte Synchronisation: NTP- und PTP-Protokolle verbessern die Genauigkeit
Blockchain-Zeitstempel: Kryptowährungen erfordern manipulationssichere, hochpräzise Zeitstempel
Performance-Optimierung: SIMD-Instruktionen, Speicher-Caching und parallele Verarbeitung beschleunigen Konvertierungen

Weiterführend

Unix-Zeitstempel-Umrechner (erkennt automatisch Sekunden, Millisekunden und Mikrosekunden)
Was steckt in einer PostgreSQL-timestamp-Spalte?

Zusammenfassung

Die wichtigste Regel: In UTC speichern, in lokaler Zeit anzeigen, und Zeitstempel-Einheiten immer explizit angeben.

Siehe auch: Entwickler-Tools

Unix-Zeitstempel: Präzision, Zeitzonen und DST-Praxis