Unix Timestamp Konverter – Zeitstempel in Datum umrechnen
Unix Timestamp Konverter
Der vollständigste Timestamp-Konverter im deutschen Web. Automatische Erkennung, Zeitzonen-Vergleich, Code-Snippets für 8 Sprachen, Timeline-Visualisierung und Lernpfad für Einsteiger bis Experten.
Vollständige Analyse des aktuellen Moments — alle Formate auf einen Blick.
Derselbe Moment — weltweit in Echtzeit. Zeigt, warum Unix-Timestamps zeitzonenneutral sind.
Mehrere Timestamps oder JSON auf einmal verarbeiten — ideal für Log-Dateien und API-Antworten.
💻 Copy-Paste Code-Snippets
Timestamps generieren und konvertieren — in 8 Sprachen, sofort einsatzbereit.
// ── Aktuellen Timestamp generieren ── const tsSeconds = Math.floor(Date.now() / 1000); // 10-stellig const tsMillis = Date.now(); // 13-stellig // ── Timestamp → Date umwandeln ── const ts = 1700000000; const date = new Date(ts * 1000); // in ms umrechnen! console.log(date.toISOString()); // "2023-11-14T22:13:20.000Z" console.log(date.toLocaleString('de-DE')); // "14.11.2023, 23:13:20" // ── Date → Timestamp umwandeln ── const myDate = new Date('2024-06-01T12:00:00Z'); const myTs = Math.floor(myDate.getTime() / 1000); // 1717243200 // ── Relative Zeit berechnen ── const relTime = ts => { const diff = (Date.now() / 1000) - ts; if (diff < 60) return `${Math.floor(diff)}s ago`; if (diff < 3600) return `${Math.floor(diff/60)}m ago`; if (diff < 86400) return `${Math.floor(diff/3600)}h ago`; return `${Math.floor(diff/86400)}d ago`; };
import time from datetime import datetime, timezone, timedelta # ── Aktuellen Timestamp generieren ── ts_seconds = int(time.time()) # 10-stellig ts_millis = int(time.time() * 1000) # 13-stellig # ── Timestamp → Datetime umwandeln ── ts = 1700000000 # UTC (empfohlen!) dt_utc = datetime.fromtimestamp(ts, tz=timezone.utc) print(dt_utc.isoformat()) # 2023-11-14T22:13:20+00:00 # Lokal (Vorsicht bei Zeitzonen!) dt_local = datetime.fromtimestamp(ts) print(dt_local.strftime('%d.%m.%Y %H:%M:%S')) # ── Datetime → Timestamp umwandeln ── my_dt = datetime(2024, 6, 1, 12, 0, 0, tzinfo=timezone.utc) my_ts = int(my_dt.timestamp()) # 1717243200 # ── Mit pytz für komplexe Zeitzonen ── # pip install pytz import pytz berlin = pytz.timezone('Europe/Berlin') dt_berlin = datetime.fromtimestamp(ts, tz=berlin)
// ── Aktuellen Timestamp generieren ── $ts = time(); // Sekunden $ts_ms = (int)(microtime(true) * 1000); // Millisekunden // ── Timestamp → Datum umwandeln ── $ts = 1700000000; // Einfach mit date() echo date('d.m.Y H:i:s', $ts); // 14.11.2023 23:13:20 echo date('c', $ts); // ISO 8601 // Mit DateTime (empfohlen für Zeitzonen) $dt = new DateTime(); $dt->setTimestamp($ts); $dt->setTimezone(new DateTimeZone('Europe/Berlin')); echo $dt->format('d.m.Y H:i:s T'); // ── Datum → Timestamp umwandeln ── $dt2 = new DateTime('2024-06-01 12:00:00', new DateTimeZone('UTC')); echo $dt2->getTimestamp(); // 1717243200 // ── Carbon (Laravel) ── // $dt = Carbon::createFromTimestamp(1700000000, 'Europe/Berlin');
import java.time.*; import java.time.format.*; // ── Aktuellen Timestamp generieren ── long tsSeconds = Instant.now().getEpochSecond(); // 10-stellig long tsMillis = System.currentTimeMillis(); // 13-stellig // ── Timestamp → Instant umwandeln ── Instant instant = Instant.ofEpochSecond(1700000000L); System.out.println(instant); // 2023-11-14T22:13:20Z // Mit Zeitzone (ZonedDateTime) ZoneId berlin = ZoneId.of("Europe/Berlin"); ZonedDateTime zdt = instant.atZone(berlin); System.out.println(zdt); // 2023-11-14T23:13:20+01:00[Europe/Berlin] // Formatieren DateTimeFormatter fmt = DateTimeFormatter.ofPattern("dd.MM.yyyy HH:mm:ss"); System.out.println(zdt.format(fmt)); // 14.11.2023 23:13:20 // ── LocalDateTime → Timestamp ── LocalDateTime ldt = LocalDateTime.of(2024, 6, 1, 12, 0); long ts = ldt.toEpochSecond(ZoneOffset.UTC); // 1717243200
using System; // ── Aktuellen Timestamp generieren ── long tsSeconds = DateTimeOffset.UtcNow.ToUnixTimeSeconds(); long tsMillis = DateTimeOffset.UtcNow.ToUnixTimeMilliseconds(); // ── Timestamp → DateTimeOffset ── long ts = 1700000000L; DateTimeOffset dto = DateTimeOffset.FromUnixTimeSeconds(ts); Console.WriteLine(dto.UtcDateTime); // 11/14/2023 10:13:20 PM Console.WriteLine(dto.ToString("o")); // ISO 8601 // Mit Zeitzone TimeZoneInfo tz = TimeZoneInfo.FindSystemTimeZoneById("W. Europe Standard Time"); DateTime localDt = TimeZoneInfo.ConvertTimeFromUtc(dto.UtcDateTime, tz); // ── DateTime → Timestamp ── DateTime myDt = new DateTime(2024, 6, 1, 12, 0, 0, DateTimeKind.Utc); long myTs = new DateTimeOffset(myDt).ToUnixTimeSeconds();
package main import ( "fmt" "time" ) func main() { // ── Aktuellen Timestamp generieren ── tsSeconds := time.Now().Unix() tsMillis := time.Now().UnixMilli() tsNanos := time.Now().UnixNano() // ── Timestamp → time.Time ── ts := int64(1700000000) t := time.Unix(ts, 0).UTC() fmt.Println(t.Format(time.RFC3339)) // 2023-11-14T22:13:20Z fmt.Println(t.Format("02.01.2006 15:04:05")) // Mit Zeitzone loc, _ := time.LoadLocation("Europe/Berlin") t_local := t.In(loc) fmt.Println(t_local.Format("02.01.2006 15:04:05 MST")) // ── time.Time → Timestamp ── myTime := time.Date(2024, time.June, 1, 12, 0, 0, 0, time.UTC) myTs := myTime.Unix() // 1717243200 _ = tsMillis; _ = tsNanos; _ = myTs }
-- ═══ MySQL / MariaDB ═══ SELECT UNIX_TIMESTAMP() AS ts_now; -- aktueller Timestamp SELECT FROM_UNIXTIME(1700000000) AS human_date; -- → '2023-11-14 23:13:20' SELECT FROM_UNIXTIME(1700000000, '%d.%m.%Y %H:%i'); SELECT UNIX_TIMESTAMP('2024-06-01 12:00:00'); -- → 1717243200 -- Zeitzonen in MySQL SELECT CONVERT_TZ(FROM_UNIXTIME(1700000000), '+00:00', 'Europe/Berlin'); -- ═══ PostgreSQL ═══ SELECT EXTRACT(EPOCH FROM NOW()) AS ts_now; SELECT to_timestamp(1700000000) AS human_date; SELECT to_timestamp(1700000000) AT TIME ZONE 'Europe/Berlin'; SELECT EXTRACT(EPOCH FROM '2024-06-01 12:00:00'::timestamp); -- ═══ SQLite ═══ SELECT strftime('%s', 'now') AS ts_now; SELECT datetime(1700000000, 'unixepoch'); SELECT datetime(1700000000, 'unixepoch', 'localtime');
# ── Aktuellen Timestamp generieren ── TS=$(date +%s) # Sekunden (GNU date + macOS) TS_MS=$(date +%s%3N) # Millisekunden (nur GNU date) # ── Timestamp → Datum (GNU date / Linux) ── date -d @1700000000 date -d @1700000000 +"%d.%m.%Y %H:%M:%S" date -d @1700000000 -u +"%Y-%m-%dT%H:%M:%SZ" # UTC/ISO # ── Timestamp → Datum (macOS BSD date) ── date -r 1700000000 date -r 1700000000 "+%d.%m.%Y %H:%M:%S" # ── Datum → Timestamp ── date -d "2024-06-01 12:00:00 UTC" +%s # GNU date date -j -f "%Y-%m-%d %H:%M:%S" "2024-06-01 12:00:00" +%s # macOS # ── Mit Python in Bash ── python3 -c "import datetime; print(int(datetime.datetime(2024,6,1,12,0,0,tzinfo=datetime.timezone.utc).timestamp()))"
Unix Timestamp – Der vollständige Lernpfad: Von Einsteiger bis Experte
Ob du gerade das erste Mal auf eine Zahl wie 1700000000 gestoßen bist oder als erfahrener Entwickler verstehen willst, warum dein 32-Bit-System 2038 Probleme bekommen wird — hier findest du alles, was du über Unix-Timestamps wissen musst. Strukturiert als progressiver Lernpfad: du kannst auf jeder Ebene einsteigen.
Level 1: Was ist ein Unix-Timestamp? (Einfach erklärt)
Die universelle Uhrenzahl — eine Analogie
Stell dir vor, alle Menschen der Welt hätten sich am 1. Januar 1970 um genau Mitternacht UTC auf einen Startschuss geeinigt. Seitdem zählt eine gigantische, niemals stehende Uhr einfach hoch: 1, 2, 3, ... Jede Sekunde eine Zahl mehr.
Diese Zahl heißt Unix-Timestamp. Sie ist der universellste, einfachste und platzsparendste Weg, einen Moment in der Zeit festzuhalten. Statt zu schreiben "Dienstag, 14. November 2023, 23:13:20 Uhr mitteleuropäischer Zeit" schreiben Computersysteme einfach: 1700000000.
Das klingt simpel — und das ist es auch. Genau das ist der Grund, warum Unix-Timestamps in praktisch jeder modernen Software, jeder Datenbank, jeder API und jedem Betriebssystem vorkommen.
Warum 1970? Die Ursprungsgeschichte
Niemand hat 1970 als magisches Jahr festgelegt. Es war schlicht pragmatisch: Als Unix in den frühen 1970ern entwickelt wurde, brauchten die Entwickler einen Referenzpunkt — und wählten den nächsten runden Zeitpunkt in der Vergangenheit. Der 1. Januar 1970 ist seitdem als Unix-Epoche bekannt — oder genauer: der Epoch-Startpunkt.
📌 Merksatz für Einsteiger
Unix-Timestamp = Anzahl vergangener Sekunden seit dem 1. Januar 1970, 00:00:00 UTC.
Wenn du dir nichts anderes merkst, merk dir das. Alles andere baut darauf auf.
Warum ist das eine gute Idee?
Die Alternative wäre, Zeitpunkte als Text zu speichern: "14.11.2023 23:13:20". Das klingt menschenlesbar, ist aber für Maschinen eine Katastrophe:
- Welches Format? DD.MM.YYYY oder MM/DD/YYYY oder YYYY-MM-DD?
- Welche Zeitzone? Lokale Zeit, UTC, oder mit Offset?
- Wie vergleicht man zwei Zeitpunkte? Texte lassen sich nicht direkt subtrahieren.
- Wie viel Speicher braucht ein Textstempel? Viel mehr als eine Zahl.
Ein Timestamp löst all das. Er ist zeitzonenunabhängig, kompakt, vergleichbar und lässt sich mit einfacher Arithmetik berechnen. "Wie viele Sekunden sind zwischen diesen beiden Ereignissen vergangen?" — einfach subtrahieren.
Level 2: Grundkenntnisse — Sekunden, Millisekunden und die 10/13-Stellen-Regel
Das wichtigste Detail: 10 Stellen vs. 13 Stellen
Du wirst zwei Arten von Timestamps begegnen, und es ist einer der häufigsten Entwicklerfehler, sie zu verwechseln:
| Format | Beispiel | Einheit | Typisch in |
|---|---|---|---|
| 10 Stellen | 1700000000 | Sekunden | Unix/POSIX, Python time.time(), PHP time(), SQL |
| 13 Stellen | 1700000000000 | Millisekunden | JavaScript Date.now(), Java System.currentTimeMillis() |
| 16 Stellen | 1700000000000000 | Mikrosekunden | Python time.time_ns(), PostgreSQL, High-Precision-Systeme |
| 19 Stellen | 1700000000000000000 | Nanosekunden | Go time.UnixNano(), Java System.nanoTime() |
Die goldene Faustregel: Unser Tool erkennt das automatisch. Aber du kannst auch selbst prüfen: Hat dein Timestamp 10 Stellen → Sekunden. Hat er 13 Stellen → Millisekunden. Alles andere: prüf die Dokumentation deiner Quelle.
⚠️ Klassischer Anfängerfehler
new Date(1700000000) in JavaScript gibt dir das Jahr 1970, nicht 2023. Denn JavaScript erwartet Millisekunden. Der richtige Aufruf: new Date(1700000000 * 1000). Dieser Fehler taucht wöchentlich auf Stack Overflow auf.
Timestamps konvertieren — So funktioniert der Rechner
?ts=1700000000) mit Kollegen, oder nutze den Massen-Konverter für viele Timestamps gleichzeitig.Level 3: Zeitzonen, UTC und warum das so kompliziert ist
Der größte Vorteil von Timestamps: Zeitzonenunabhängigkeit
Der Timestamp 1700000000 ist immer und überall auf der Welt identisch. Er beschreibt einen absoluten Moment im Universum. Ob du in Berlin, Tokyo oder New York bist — dieselbe Zahl bedeutet dasselbe: 14. November 2023, 22:13:20 UTC.
Erst wenn du diese Zahl in ein lesbares Datum umwandelst, kommt die Zeitzone ins Spiel. Dann ist es:
- In Berlin (CET, UTC+1): 23:13:20
- In London (GMT, UTC+0): 22:13:20
- In New York (EST, UTC-5): 17:13:20
- In Tokyo (JST, UTC+9): 07:13:20 am nächsten Tag
Das ist kein Bug — das ist der Sinn. Immer UTC speichern, erst bei der Anzeige in lokale Zeit konvertieren. Wenn du diesen Grundsatz einhältst, wirst du keine Zeitzone-Bugs haben.
UTC vs. GMT — der Unterschied
In der Praxis werden UTC und GMT oft synonym verwendet — für Timestamps macht der Unterschied keine Rolle. Technisch gesehen ist UTC (Coordinated Universal Time) der modernere Standard, der auf Atomuhren basiert. GMT (Greenwich Mean Time) ist historisch und astronomisch definiert. Unix-Timestamps sind definitiv UTC.
Sommerzeit (DST) — das unsichtbare Problem
Stell dir vor, du loggst ein Ereignis mit einem lesbaren Datum-String: "2024-10-27 02:30:00". Gibt es diesen Moment in Deutschland? Zweimal. Denn um 3:00 Uhr MESZ wird die Uhr auf 2:00 Uhr MEZ zurückgestellt — und "02:30 Uhr" gibt es sowohl als Sommerzeit als auch als Winterzeit.
Mit einem Unix-Timestamp existiert dieses Problem nicht. 1729988400 ist genau ein Moment, kein mehrdeutiger Datum-String. Das ist der Hauptgrund, warum professionelle Systeme immer Timestamps speichern und niemals lokale Datum-Strings.
💡 Best Practice: UTC in, lokale Zeit out
Speichere in deiner Datenbank immer den Unix-Timestamp oder explizit UTC. Konvertiere die Zeit in lokale Zeitzonen nur für die Anzeige im Frontend — niemals vorher.
ISO 8601 vs. Unix-Timestamp
ISO 8601 ist der internationale Standard für Datum-/Uhrzeitdarstellung: 2023-11-14T22:13:20Z. Das "Z" am Ende steht für UTC. Dieses Format ist menschenlesbar und maschinenverarbeitbar.
| Kriterium | Unix-Timestamp | ISO 8601 | Lokaler String |
|---|---|---|---|
| Menschenlesbar | ✕ | ✓ | ✓ |
| Kompakt | ✓ (10 Bytes) | ✕ (24 Bytes) | ✕ (variabel) |
| Zeitzonenunabhängig | ✓ | ✓ (mit Z/Offset) | ✕ |
| Direkt vergleichbar | ✓ (Zahl) | ✓ (lexikografisch) | ✕ |
| Arithmetik möglich | ✓ (+86400 = +1 Tag) | ✕ | ✕ |
| DST-sicher | ✓ | ✓ (wenn UTC) | ✕ |
Level 4: Experte — Interna, 32-Bit-Limit und das Jahr-2038-Problem
Wie Timestamps intern gespeichert werden
Unter der Haube ist ein Unix-Timestamp eine ganze Zahl (integer). Auf 32-Bit-Systemen wird sie als vorzeichenbehafteter 32-Bit-Integer gespeichert (int32_t). Das bedeutet:
- Maximaler Wert:
2.147.483.647(231 - 1) - Minimaler Wert:
-2.147.483.648(negative Timestamps = vor 1970) - Reichweite: 1. Januar 1970 bis 19. Januar 2038
Auf 64-Bit-Systemen (alle modernen Rechner, Server und Smartphones) ist der Timestamp ein 64-Bit-Integer. Der maximale Wert ist astronomisch groß — er reicht bis ins Jahr 292 Milliarden. Das Jahr-2038-Problem existiert hier schlicht nicht.
Das Y2K38-Problem in der Praxis
Am 19. Januar 2038 um 03:14:07 UTC schlägt der 32-Bit-Timestamp zum letzten Mal. Eine Sekunde danach — bei 2.147.483.648 — rollt er auf den kleinsten negativen 32-Bit-Integer um: -2.147.483.648. Für das System bedeutet das plötzlich: Es ist der 13. Dezember 1901.
Das klingt abstrakt, hat aber in eingebetteten Systemen, älteren Linux-Kerneln, Datenbanken mit INT(11) für Timestamps und IoT-Geräten mit 32-Bit-Prozessoren reale Konsequenzen. Ein Kühlschrank der 2020er Jahre könnte 2038 plötzlich denken, er sei fast 40 Jahre in der Vergangenheit.
🔴 Prüfliste für 2038-Sicherheit
✅ Datenbankspalten als BIGINT (nicht INT) für Timestamps
✅ MySQL: TIMESTAMP durch DATETIME ersetzen (DATETIME unterstützt bis 9999)
✅ 32-Bit-Betriebssysteme aktualisieren oder migrieren
✅ Eingebettete Systeme mit Long-Laufzeit auf 64-Bit prüfen
Präzision: Wann reichen Sekunden nicht aus?
Für die meisten Anwendungen sind Sekunden-Timestamps vollkommen ausreichend. Aber es gibt Szenarien, in denen mehr Präzision gebraucht wird:
- Millisekunden: Web-APIs, JavaScript, Datenbankabfragen mit Performance-Logging
- Mikrosekunden: PostgreSQL
TIMESTAMP WITH TIME ZONE, Netzwerk-Latenz-Messung - Nanosekunden: High-Frequency-Trading, wissenschaftliche Messungen, Prozessor-Profiling
Real-World Use Cases: Timestamps in der Praxis
Viele APIs — darunter GitHub, Stripe, Twitter/X und AWS — liefern Timestamps in ihren JSON-Antworten. Ein typisches GitHub-API-Response:
Stripe und viele andere Dienste verwenden Sekunden-Timestamps in ihren APIs. Wenn du eine charge aus der Stripe API liest und "created": 1700000000 siehst, weißt du jetzt sofort: Diese Zahlung wurde am 14. November 2023 erstellt.
Typische Felder in APIs: created_at, updated_at, timestamp, time, date, epoch. Achte auf den Feldtyp: Ist es ein string (ISO 8601) oder ein number (Unix-Timestamp)?
Server-Logs enthalten oft Unix-Timestamps im Combined-Log-Format oder in speziellen Access-Log-Formaten:
Wenn du Logs analysierst und dabei Timestamps findest: Kopiere einfach die Zahl in unseren Massen-Konverter oben auf dieser Seite — du kannst Dutzende auf einmal konvertieren.
JWT (JSON Web Tokens) enthalten standardmäßig zwei Timestamp-Felder, die du häufig debuggen musst:
JWT-Tokens werden mit Base64 kodiert. Mit unserem JWT Decoder kannst du den Token direkt dekodieren, und dann die iat und exp Werte hier konvertieren, um zu sehen wann genau dein Token ausläuft.
Häufiges Problem: exp: 1700000000 zu debuggen und festzustellen, dass dein Token vor drei Monaten abgelaufen ist — das erklärt deine 401-Fehler.
Beim direkten Zugriff auf Datenbankdaten via SQL-Client oder Export siehst du oft rohe Integer-Timestamps:
Vorsicht in MySQL: Der Spaltentyp TIMESTAMP hat eine Obergrenze am 19. Januar 2038 (Y2K38-Problem!). Für zukünftssichere Anwendungen verwende stattdessen DATETIME (Reichweite bis 9999) oder speichere als BIGINT.
Timestamps sind ideal für Ablauf-Logik (expiration), weil du einfach addieren kannst:
Nützliche Konstanten: 60 = 1 Minute, 3600 = 1 Stunde, 86400 = 1 Tag, 604800 = 1 Woche, 2592000 = 30 Tage.
Häufige Fehler mit Unix-Timestamps
// lokal nur bei Anzeige konvertieren
Häufige Fragen zum Unix Timestamp Konverter
-86400 dem 31. Dezember 1969, 00:00:00 UTC. Unser Konverter unterstützt negative Timestamps vollständig. Wichtig: Prüfe in deinem Code niemals Timestamps mit einem einfachen if (!ts) — das würde den Wert 0 (1.1.1970) und negative Werte fälschlicherweise ausschließen.Date.now() gibt daher immer Millisekunden zurück — das ergibt 13 Stellen. Um den klassischen 10-stelligen Sekunden-Timestamp zu erhalten, teile durch 1000: Math.floor(Date.now() / 1000). Vergisst du die Division, gibt new Date(timestamp) fälschlicherweise das Jahr 1970 zurück.date -d @1700000000 (GNU date) oder date -r 1700000000 (BSD/macOS). Den aktuellen Timestamp erhältst du mit date +%s. Für Millisekunden: date +%s%3N (nur GNU date). In Python: python3 -c "import datetime; print(datetime.datetime.fromtimestamp(1700000000))".Datenschutz & DSGVO
Alle Berechnungen auf dieser Seite finden ausschließlich lokal in deinem Browser statt. Kein Timestamp, kein Datum und keine deiner Eingaben verlässt deinen Computer. Es werden keine Daten an Server übertragen, gespeichert oder analysiert. Das gilt für alle Tools auf werkix.de: vollständig DSGVO-konform, ohne Cookies für die Tool-Funktion, ohne Tracking deiner Eingaben.
Der Verlauf (History) wird ausschließlich im localStorage deines Browsers gespeichert — lokal, auf deinem Gerät, niemals auf einem Server.
.png)
