Unix-Zeitstempel Wie man umrechnet und warum sie überall vorkommen

Ein Unix-Timestamp ist die Anzahl der seit dem 1. Januar 1970, 00:00:00 UTC vergangenen Sekunden — auch als Unix-Epoch bezeichnet. Dieses Datum wurde nicht aus technischen Gründen gewählt; es war einfach das Jahr, in dem Unix entwickelt wurde. Die Epoch ist immer UTC, was bedeutet, dass ein Timestamp wie 1712800000 die gleiche Zeit überall auf der Erde darstellt, unabhängig von der Zeitzone.

Unix-Timestamps werden überall verwendet: HTTP-Header, JWT-Tokens, Datenbankaufzeichnungen, Protokolldateien, Nachrichtenqueues und API-Antworten. Wenn Sie etwas mit Zeit zu tun haben, werden Sie sie ständig treffen. Der IO Tools Unix-Timestamp-Converter ist nützlich für schnelle Abfragen, aber Sie müssen auch wissen, wie man sie in Code verarbeitet.

Sekunden vs. Millisekunden: Der Fehler, der alle betrifft

Der häufigste Timestamp-Fehler in der Produktion: Verwirrung zwischen Sekunden und Millisekunden. Das Unix-Standardformat verwendet Sekunden. JavaScripts Date.now() gibt Millisekundenaus. Ebenso Javas System.currentTimeMillis().

Ein Timestamp von 1712800000 ist April 2024. Ein Timestamp von 1712800000000 (Millisekunden) ist ein Jahr um 56.000. Wenn Ihre Datumsberechnungen zukünftige Daten generieren oder anzeigen, ist dies fast immer der Grund. 1970-01-01Regel: Wenn der Timestamp 13 Stellen hat, handelt es sich um Millisekunden. Bei 10 Stellen um Sekunden. Wenn Sie unsicher sind, teilen Sie durch 1000 und prüfen, ob das Ergebnis sinnvoll ist.

Umrechnung von Unix-Timestamps je Sprache

Hier sind die Muster, die Sie tatsächlich verwenden werden:

SQL (MySQL / MariaDB)

JavaScript

// Get current timestamp (milliseconds — divide by 1000 for seconds)
const tsMs = Date.now();           // e.g. 1712800000000
const tsSec = Math.floor(Date.now() / 1000); // e.g. 1712800000

// Convert seconds timestamp to Date object
const ts = 1712800000;
const date = new Date(ts * 1000);  // must multiply by 1000
console.log(date.toISOString());   // "2024-04-11T02:13:20.000Z"

// Convert Date back to Unix timestamp (seconds)
const tsBack = Math.floor(date.getTime() / 1000);

Python

from datetime import datetime, timezone

# Get current timestamp (seconds)
import time
ts = int(time.time())  # e.g. 1712800000

# Convert timestamp to datetime (UTC-aware)
dt = datetime.fromtimestamp(ts, tz=timezone.utc)
print(dt.isoformat())  # 2024-04-11T02:13:20+00:00

# Convert local-naive datetime to timestamp (risky — see timezone section)
ts_back = int(dt.timestamp())

Aktuelle (Sekunden)

-- Convert timestamp to datetime
SELECT FROM_UNIXTIME(1712800000);
-- Result: 2024-04-11 02:13:20 (server timezone applies here)

-- Get current Unix timestamp
SELECT UNIX_TIMESTAMP();

-- Convert datetime string to timestamp
SELECT UNIX_TIMESTAMP('2024-04-11 02:13:20');

Bash

# Get current timestamp
date +%s

# Convert timestamp to human-readable (GNU date)
date -d @1712800000
# Output: Thu Apr 11 02:13:20 UTC 2024

# macOS (BSD date)
date -r 1712800000

Schnellreferenz-Tabelle

Unix-Timestamps sind immer UTC. Immer. Die Zahl

hat keine Zeitzone — sie zählt einfach Sekunden seit der Epoch. Zeitzone ist ein Anzeigeproblem, kein Speicherproblem. 1712800000 Wo Entwickler in Schwierigkeiten geraten:

Python’s

• ohne datetime.fromtimestamp(ts) — verwendet die lokale Zeitzone des Servers, stumm. Verwenden Sie tz=timezone.utc MySQL’s fromtimestamp(ts, tz=timezone.utc) stattdessen.
• — wandelt in die Zeitzone des MySQL-Servers um ( FROM_UNIXTIME() ). Wenn Ihr Server in UTC+8 ist, verschiebt sich das Ergebnis um 8 Stunden.@@session.time_zoneSpeichern von
• in MySQL ohne UTC-Normalisierung datetime — wenn Ihr App- und Datenbankserver in verschiedenen Zeitzone liegen, ist jede Einfügung oder Abfrage ein Fehler, der passieren kann. Das Muster, das alle diese Probleme vermeidet: Speichern von Unix-Timestamps in der Datenbank, Umrechnung in menschlesbare Formate zur Anzeige in der Anwendungsschicht, mit der bevorzugten Zeitzone des Benutzers.

Timestamps vs. ISO 8601-Zeichenketten: Was zu speichern ist

Beide sind gültige Speicherformate. Die Abwägung:

Unix-Timestamp (Ganzzahl)

• : kompakt, schnell für Vergleiche und Rechnungen, keine Zeitzone-Verwirrung, funktioniert auf allen Datenbank-Engines. Nachteil: nicht menschlesbar ohne ein Tool.ISO 8601-Zeichenkette
• (z. B. ): menschlesbar in der Datenbank, selbst dokumentierend. Nachteil: langsamer bei Intervallabfragen, Zeitzone kann versehentlich weggelassen oder falsch eingegeben werden. 2024-04-11T02:13:20ZFür die meisten Anwendungen: Speichern von Timestamps als ganze Zahlen. Verwenden Sie ISO 8601 bei APIs und Protokollen, wo menschliche Lesbarkeit wichtig ist. Wenn Sie ISO 8601 speichern müssen, geben Sie immer die

oder explizite Offset an — ein Z ohne Zeitzone ist ein Katastrophe in verteilten Systemen. 2024-04-11 02:13:20 Das Problem von 2038

32-Bit-gesignierte ganze Zahlen können einen maximalen Wert von

aufweisen, der dem 1. Januar 2038, 03:14:07 UTC entspricht. Systeme, die Unix-Timestamps in 32-Bit 2147483647speichern, überschreiten diesen Wert und rollen zurück auf 1901 oder crashen. int Sollten Sie sich Sorgen machen? Wenn Sie neue Code schreiben, nein — verwenden Sie 64-Bit-Zahlen. Wenn Sie alte C-Code, eingebettete Firmware oder ältere MySQL-Schemata mit

für Timestamps verwenden, lohnt sich eine Prüfung. MySQLs INT(11) Typ ist ebenfalls betroffen; TIMESTAMP ist es nicht. Moderne Systeme mit 64-Bit-Timestamps sind sicher bis weit in das Jahr 292 Milliarden. DATETIME Müssen Sie Timestamps schnell umrechnen, ohne Code zu schreiben? Der

Unix-Timestamp-Converter auf IO Tools behandelt Sekunden und Millisekunden, zeigt die UTC- und lokale Zeit nebeneinander an und lässt Sie ein Datum einfügen, um den Timestamp zurückzubekommen. Unix-Timestamps: Wie man sie umrechnet und warum sie überall vorkommen 1

Das könnte Ihnen auch gefallen

Neu

Markdown vs HTML: When to Use Each for Docs, READMEs, and APIs

Mehr lesen "

Veröffentlicht am Mai 9, 2026

Neu

UTM-Parameter: Wie man Marketing-Kampagnen ohne Spekulation verfolgt

Mehr lesen "

Veröffentlicht am 8. Mai 2026

Neu

Farbbarriere für Entwickler: Kontrast, Simulation von Sehbehinderungen und Fehlerbehebung

Mehr lesen "

Veröffentlicht am 7. Mai 2026

Neu

WebP gegen AVIF gegen PNG gegen JPEG: Die Auswahl von Bildformaten für das Web

Mehr lesen "

Veröffentlicht am 6. Mai 2026