Die aktuelle Unix-Zeit und Konvertierung zwischen Timestamp und Datum.
Ein Unix Timestamp (auch Epoch Time oder POSIX Time) ist die Anzahl der Sekunden, die seit dem 1. Januar 1970 00:00:00 UTC vergangen sind. Dieses Datum wird als 'Unix Epoch' bezeichnet. Unix Timestamps werden in nahezu allen Betriebssystemen, Datenbanken und Programmiersprachen als Standard-Zeitformat verwendet.
Der klassische Unix Timestamp zählt in Sekunden (10 Ziffern, z.B. 1700000000). Viele moderne Systeme wie JavaScript (Date.now()) verwenden jedoch Millisekunden (13 Ziffern, z.B. 1700000000000). Dieses Tool erkennt automatisch, ob ein Wert in Sekunden oder Millisekunden angegeben ist.
Am 19. Januar 2038 um 03:14:07 UTC erreicht ein 32-Bit-Unix-Timestamp seinen maximalen Wert (2147483647). Systeme, die noch 32-Bit-Integer für Timestamps verwenden, werden dann einen Überlauf erleben. Moderne 64-Bit-Systeme sind davon nicht betroffen.
0 — 1. Januar 1970 00:00:00 UTC (Unix Epoch)1000000000 — 9. September 2001 01:46:40 UTC1700000000 — 14. November 2023 22:13:20 UTC2000000000 — 18. Mai 2033 03:33:20 UTC2147483647 — 19. Januar 2038 03:14:07 UTC (32-Bit Max)Diese Timestamps tauchen besonders oft in Suchanfragen, API-Antworten oder Datenbankexports auf — direkt zur Detailseite mit lokaler Zeit, ISO 8601 und weiteren Formaten:
1764244800 — 2025-11-27 12:00:00 UTC
1764432000 — 2025-11-29 16:00:00 UTC
1768175999 — 2026-01-11 23:59:59 UTC
Als Ken Thompson und Dennis Ritchie 1969 begannen, Unix zu schreiben, brauchten sie eine simple, monoton steigende Zählung von Sekunden. Die Wahl fiel auf den 1. Januar 1970, 00:00:00 UTC als Nullpunkt — die sogenannte "Unix Epoch". Diese Konvention überlebte alle Architekturen, alle Linux-Distributionen, jede Datenbank-Engine, jede Programmiersprache: Java System.currentTimeMillis(), PostgreSQL epoch, Excel-Funktion UNIX_TIMESTAMP(), JavaScript Date.now() — alle verweisen auf denselben Ankerpunkt. POSIX standardisierte den Typ als time_t in IEEE Std 1003.1. Der Charme: ein Unix-Timestamp ist sprach- und zeitzonenunabhängig. Eine einzelne ganze Zahl wie 1718000000 beschreibt einen exakten Moment auf der Erde, egal ob in Tokio, Berlin oder Lima abgelesen.
Der wichtigste Unterschied im Alltag ist Sekunden vs. Millisekunden. Klassisches Unix arbeitet in Sekunden (10-stellige Zahl wie 1718000000), JavaScript und Java in Millisekunden (13-stellige Zahl wie 1718000000000). Mikro- und Nanosekunden findet man in Datenbanken (PostgreSQL TIMESTAMP, Linux clock_gettime) sowie in Hochfrequenz-Handel und Tracing-Systemen. Dieses Tool erkennt 13-stellige Eingaben automatisch als Millisekunden und teilt durch 1000. Wer Logs verschiedener Systeme abgleicht, sollte sich der unterschiedlichen Auflösungen bewusst sein — sonst liegt ein Eintrag scheinbar im Jahr 56 088 statt im Jahr 2024.
Eine subtile Eigenheit: Unix-Time ignoriert Schaltsekunden. Während die International Earth Rotation Service (IERS) bei Bedarf eine Schaltsekunde in UTC einfügt — zuletzt am 31. Dezember 2016 — bleibt die Unix-Sekundenzählung kontinuierlich. Praktisch heißt das: time_t zählt Mittagspausen zwischen Schaltsekunden gleich, behandelt sie aber so, als ob alle Tage exakt 86 400 Sekunden lang wären. Für Anwendungen, die astronomisch korrekte UT1-Zeit brauchen (Satellitennavigation, Astronomie), reicht Unix-Time nicht — dann braucht man TAI oder GPS-Zeit. Für 99,99 % der Webentwickler, Buchhalter und Datenanalysten ist das aber irrelevant.
Vom ISO-Datum zur Unix-Sekunde: unix = (UTC-Millisekunden seit 1970-01-01) / 1000. In den meisten Sprachen: Date.UTC(year, month-1, day, hour, min, sec) / 1000 (JavaScript), mktime() bzw. strtotime() (PHP), datetime.timestamp() (Python). Umgekehrt: date = new Date(unix * 1000) bzw. date('Y-m-d H:i:s', $unix). Pro Tag werden 86 400 Sekunden hinzugefügt, pro Stunde 3 600. Wer aus Excel kommt: Excel-Serial × 86 400 − 2 209 161 600 = Unix-Sekunden (Mac-Konvention) bzw. − 2 209 161 600 für Windows. Für ISO 8601-Strings nutzt JavaScript intern Date.parse('2024-06-09T12:00:00Z') und liefert Millisekunden.
Ein paar Anker-Timestamps zur schnellen Orientierung:
1738200000 = 2025-01-30 04:00:00 UTC (Donnerstag) — entspricht 05:00 Berlin (MEZ).1893456000 = 2030-01-01 00:00:00 UTC — beliebter Long-Term-Cache-Header-Wert.2147483647 = 2038-01-19 03:14:07 UTC — exakte Obergrenze für 32-Bit-signed time_t (Y2038-Problem).0 = 1970-01-01 00:00:00 UTC (Donnerstag) — der Ursprung; negative Werte sind möglich und stehen für Daten davor.1717891200000 (13 Stellen, ms) = 2024-06-09 00:00:00 UTC — typische JavaScript-Ausgabe von Date.UTC(2024,5,9).Drei Themen schlagen regelmäßig zu. Das prominenteste ist das Y2038-Problem: ein 32-Bit-signed time_t überläuft am 2038-01-19 03:14:08 UTC und springt auf eine negative Zahl — alte eingebettete Systeme (Router, Industrie-PCs, Bordcomputer) können hängen bleiben. Linux-Kernel ab 5.6 verwenden 64-Bit-time_t auch auf 32-Bit-Plattformen; PHP 8 und Node.js arbeiten ohnehin in 64-Bit-Integern bzw. Doubles. Zweitens: Sommerzeit ist in Unix-Time nicht codiert. Beim Anzeigen muss der Empfänger die lokale Zeitzone selbst anwenden — die IANA-Datenbank (tzdata) liefert dafür die Regeln pro Region, inklusive historischer DST-Änderungen. Drittens das Sekunden-vs-Millisekunden-Problem: gibst du versehentlich 1718000000000 als Sekunden ein, landest du bei einem Datum im Jahr 56 088. Faustregel: 10-stellige Zahl heute = Sekunden, 13-stellige = Millisekunden.
-1 entspricht 1969-12-31 23:59:59 UTC. Negative Werte sind im POSIX-Standard erlaubt, werden aber von vielen Systemen nicht sauber unterstützt (z. B. Windows-MFC-Zeitfunktionen).time() liefert Sekunden, JavaScript Date.now() Millisekunden — Faktor 1000. Außerdem nutzt PHP die Zeitzone aus date_default_timezone_set bzw. php.ini, JavaScript die Browser-Zeitzone — wenn du strtotime('today') mit JavaScript-Mitternacht vergleichst, kann es um wenige Stunden abweichen.