Kostenloser Unix-Epoch-Zeitstempel-Konverter

Was Unix-Epoch-Zeit wirklich ist

Unix-Epoch-Zeit (auch POSIX-Zeit, Unix-Zeit oder einfach „Epoch“ genannt) ist ein System zur Darstellung von Zeitpunkten als einzelne Ganzzahl: die Anzahl der Sekunden (oder Millisekunden, in JavaScript und vielen modernen Systemen) seit der Unix-Epoch um 00:00:00 UTC am 1. Januar 1970. Negative Zahlen stehen für Zeiten vor der Epoch, positive für danach. Die Darstellung als einzelne Ganzzahl hat überzeugende Eigenschaften: sie ist zeitzonenunabhängig (die Zahl ist überall auf der Erde im selben Augenblick gleich), leicht zu vergleichen (spätere Zeiten sind größere Zahlen) und Dauern lassen sich trivial berechnen (Subtraktion). Unix-Zeit ist die zugrunde liegende Zeitdarstellung in praktisch jedem Betriebssystem, jeder Datenbank-Engine, jedem API-Protokoll und jeder Standardbibliothek einer Programmiersprache, selbst Systeme, deren Benutzeroberflächen Kalenderdaten anzeigen, speichern die zugrunde liegenden Werte als Epoch-Ganzzahlen.

Die Wahl des 1. Januar 1970, und andere Epochs

Die Epoch 1970-01-01 stammt aus den Anfangstagen von Unix in den Bell Labs. Unix' time_t-Typ war ursprünglich eine vorzeichenbehaftete 32-Bit-Ganzzahl, die Sekunden seit einem gewählten Bezugszeitpunkt zählte; das Team wählte das jüngste Neujahr vor dem Beginn der Entwicklung, also den 1. Januar 1970. Die Entscheidung war praktisch, nicht philosophisch, Unix wurde 1969-1971 entwickelt, und eine junge Epoch maximierte den nutzbaren Bereich der Timestamps innerhalb des vorzeichenbehafteten 32-Bit-Bereichs. Andere Systeme wählten andere Epochs, die zu ihren Anwendungsfällen passten. NTP (Network Time Protocol, RFC 5905) verwendet den 1. Januar 1900, wichtig, weil NTP längere historische Bereiche abdecken musste. Windows FILETIME verwendet den 1. Januar 1601 als Epoch in 100-Nanosekunden-Ticks (der Beginn des 400-jährigen gregorianischen Zyklus, der 1601 enthielt). VAX/VMS verwendete den 17. November 1858 (die in der Astronomie beliebte Modified-Julian-Day-Epoch). Mac classic verwendete den 1. Januar 1904. JavaScript Date verwendet die Unix-Epoch, zählt aber Millisekunden statt Sekunden (ein 64-Bit-Float mit ±100 Millionen Jahren nutzbarem Bereich). Fazit: Die Unix-Epoch dominiert 2026, aber der historische Datenbestand enthält viele andere Wahlen, jede mit eigenem Rückwärtskompatibilitäts-Erbe.

Das Y2K38-Problem, die Unix-Zeit läuft ab (gewissermaßen)

Wenn time_t eine vorzeichenbehaftete 32-Bit-Ganzzahl ist (das ursprüngliche Unix-Design), beträgt der maximal darstellbare Timestamp 2.147.483.647, was dem Dienstag, 19. Januar 2038, 03:14:07 UTC entspricht. Eine Sekunde später läuft der Wert ins Negative über und wickelt sich auf den 13. Dezember 1901 zurück. Das ist das Y2K38-Problem (auch Epochalypse genannt). Auf modernen 64-Bit-Systemen ist time_t eine vorzeichenbehaftete 64-Bit-Ganzzahl und das Überlaufdatum ist der 4. Dezember 292.277.026.596, bequem nach dem Tod der Sonne. Aber 32-Bit-Embedded-Systeme sind weiterhin aktiv im Einsatz in Industriesteuerungen, Satelliten mit langen Missionen, Backend-Systemen von Banken, SCADA-Netzen der Öl- und Gasindustrie, Auto-Infotainment und IoT-Sensoren mit jahrzehntelangen Lebensdauern. Die Mitigation läuft seit Anfang der 2000er Jahre, jedes große Betriebssystem, jede Datenbank und jede Sprache nutzt jetzt standardmäßig 64-Bit-Zeit auf 64-Bit-Hardware (Linux schloss den Wechsel im Kernel 5.6 im März 2020 ab; Windows nutzte schon immer 64 Bit; macOS Catalina ließ 2019 die 32-Bit-Unterstützung fallen). Die Embedded-Systeme sind der Long Tail. Das Y2K38-Problem wird keine Eintageskrise wie Y2K, sondern eine Serie kleiner Ausfälle in Long-Tail-Systemen über die Jahre hin zu 2038, genau so, wie sich Y2K vor allem in obskuren, ungepatchten Systemen manifestierte.

ISO 8601, das andere Standardzeit-Format

Wo Unix-Zeit das Wire-Format ist, ist ISO 8601 das menschenlesbare Format. Ursprünglich als ISO 8601:1988 veröffentlicht, in den Jahren 2000, 2004 revidiert und zuletzt in ISO 8601-1:2019 und ISO 8601-2:2019, definiert der Standard Darstellungen wie 2026-05-03T14:30:00Z (das Z bedeutet UTC) oder 2026-05-03T14:30:00+01:00 (mit explizitem Offset). Das „T“ trennt Datum von Uhrzeit; der Offset am Ende beseitigt die Zeitzonen-Mehrdeutigkeit. Für Internet-Protokolle definiert RFC 3339 (Klyne und Newman, 2002) eine strikte Teilmenge von ISO 8601, die einfacher zu parsen ist, das ist das Format, das man in JSON-API-Antworten, Log-Timestamps, JWT-exp/iat-Feldern und OAuth-Flows sieht. Das Verhältnis zur Unix-Zeit: ISO 8601 ist die menschenlesbare Form eines Zeitpunkts; Unix-Zeit ist die Ganzzahlform desselben Zeitpunkts. Ein Konverter wie dieser bewegt sich in beide Richtungen zwischen ihnen. Die Lokalzeit-Form (2026-05-03T14:30:00 ohne Offset) ist mehrdeutig und sollte in jedem System vermieden werden, das Zeitzonen überschreitet, sie ist häufig die Quelle subtiler Bugs, in denen eine JSON-API behauptet, Timestamps zurückzugeben, aber nicht angibt, in welcher Zeitzone.

Sekunden vs. Millisekunden, die häufige Verwechslung

Auf Betriebssystem-Ebene zählt Unix-Zeit Sekunden: eine 10-stellige Ganzzahl für jeden Zeitpunkt zwischen ungefähr 2001 und 2286 (Timestamps vor 2001 hatten 9 Stellen oder weniger). JavaScripts Date.now(), das System.currentTimeMillis() der JVM, das DateTimeOffset.ToUnixTimeMilliseconds() von .NET und die meisten Web-APIs zählen Millisekunden: eine 13-stellige Ganzzahl für denselben Bereich. Die beiden Formen unterscheiden sich um genau einen Faktor 1.000, und der häufigste timestamp-bezogene Bug in Code, der mit mehreren Systemen redet, ist, einen Millisekunden-Wert in eine Funktion zu füttern, die Sekunden erwartet (was ein Datum 1.000× weiter in der Zukunft als beabsichtigt ergibt) oder umgekehrt (ein Datum eine Bruchteilssekunde nach der Epoch). Dieser Konverter erkennt anhand der Stellenzahl automatisch: 10 oder weniger Stellen = Sekunden, 13 oder mehr = Millisekunden. Bei Werten dazwischen (11–12 Stellen, mehrdeutig) bevorzugt der Konverter die Interpretation, die ein sinnvolles Datum ergibt. Mikrosekunden (16 Stellen, von einigen hochpräzisen Systemen und vielen Datenbank-TIMESTAMP-Typen verwendet) und Nanosekunden (19 Stellen, von Linux clock_gettime, Gos time.UnixNano(), modernem Observability-Tooling wie OpenTelemetry verwendet) tauchen ebenfalls auf, sind aber in nutzerseitigen Daten seltener.

Wo du diese Umrechnung wirklich brauchst

• Lesen von API-Antworten. Ein REST-Endpunkt liefert "created_at": 1714665600: was ist das für ein Datum? Einfügen, „2. Mai 2024 16:00:00 UTC“ lesen, mit der Debug-Sitzung weitermachen. Stripe, GitHub, AWS und die meisten Enterprise-APIs verwenden Unix-Zeit-Ganzzahlen für Datumsfelder gerade um Zeitzonen-Mehrdeutigkeit zu vermeiden.
• Decodieren von Log-Timestamps. Server-Logs erfassen Zeiten oft als Unix-Ganzzahlen aus Gründen der Kompaktheit und Parsing-Geschwindigkeit. Das Lesen von „1714665600.234 ERROR connection refused“ erfordert die Umrechnung der führenden Zahl in eine Kalenderzeit, um sie mit anderen Ereignissen zu korrelieren.
• JWT-Debugging. Die Claims exp (Ablauf) und iat (issued-at) in JSON Web Tokens sind Unix-Zeit-Ganzzahlen gemäß RFC 7519. Um zu prüfen, ob ein Token abgelaufen ist, oder zu sehen, wann er ausgestellt wurde, fügst du den Wert hier ein.
• Berechnung von Zeitdifferenzen. Subtrahiere zwei Unix-Timestamps, um die Dauer dazwischen in Sekunden (oder Millisekunden) zu erhalten. Keine Zeitzonen-Mathematik, keine DST-Anpassung, keine Kalender-Arithmetik-Sonderfälle.
• Datenbankabfragen mit Epoch-Spalten. Viele ältere Datenbanken speichern Timestamps als Unix-Ganzzahlen. Eine Abfrage „alle Ereignisse zwischen X und Y“ erfordert die Umrechnung lesbarer Stichdaten in Unix-Ganzzahlen für die WHERE-Klausel.
• Planung und Cron-Aufgaben. Systeme, die Jobs nach absoluter Zeit einplanen (Kubernetes CronJobs, AWS EventBridge, Azure Logic Apps), möchten in ihrer Konfiguration oft Unix-Zeit-Ziele. Rechne die menschenfreundliche Zielzeit in Epoch um.
• Decodieren „interessanter“ Timestamps. Bekannte Epoch-Werte: 0 = 1. Januar 1970 00:00:00 UTC (die Epoch selbst); 1234567890 = 13. Februar 2009 23:31:30 UTC (kurz als „Unix billion“-Moment gefeiert); 1500000000 = 14. Juli 2017 02:40:00 UTC; 2000000000 = 18. Mai 2033 03:33:20 UTC; 2147483647 = 19. Januar 2038 03:14:07 UTC (der Y2K38-Überlaufpunkt).

Eine Notiz zu Schaltsekunden und „echter“ Zeit

Eine subtile Komplikation: Unix-Zeit, wie POSIX sie definiert, enthält keine Schaltsekunden. Die koordinierte Weltzeit (UTC) fügt gelegentlich eine Schaltsekunde ein, um die zivile Zeit an die tatsächliche Erdrotation anzupassen, seit dem Start des Systems 1972 wurden 27 Schaltsekunden hinzugefügt. Unix-Zeit tut so, als hätten diese Schaltsekunden nicht stattgefunden: Wird am Tagesende eine Schaltsekunde eingefügt, wiederholt die Uhr entweder die letzte Sekunde (Linux' traditionelles Verhalten) oder verteilt sie über einen längeren Zeitraum (Googles „Leap Smear“-Ansatz, von AWS und vielen CDNs übernommen). Für die meisten Anwendungsfälle ist das egal, Sub-Sekunden-Genauigkeit ist auf Anwendungsebene selten bedeutsam. Für hochpräzise wissenschaftliche Arbeit, Timestamps in Finanz-Trading-Systemen oder gerichtsverwertbare Timestamps ist das Schaltsekundenverhalten eine bekannte Quelle von Sonderfällen. Der IERS (International Earth Rotation and Reference Systems Service) kündigt Schaltsekunden mit sechs Monaten Vorlauf an; die jüngste wurde am Ende des 31. Dezember 2016 eingefügt, und die internationale Gemeinschaft erwägt, Schaltsekunden ganz abzuschaffen (die Resolution, dies bis 2035 zu tun, wurde auf der 2022er Generalkonferenz für Maß und Gewicht beschlossen).

Datenschutz: Umrechnung nur im Browser

Timestamps, die du einfügst, sind in der Regel selbst nicht sensibel (eine Unix-Ganzzahl verrät nur einen Zeitpunkt), aber der Kontext, eine Logzeile, die neben dem Timestamp eine echte Nutzer-ID enthält, ein JWT mit Claims über einen echten Nutzer, eine API-Antwort mit internen Entitäts-IDs (ist es häufig. Dieser Konverter läuft komplett in deinem Browser über JavaScripts eingebaute Date-API. Kein Upload, kein Logging) verifiziere im Network-Tab der DevTools, während du einen Timestamp tippst (es feuert keine Anfrage), oder schalte die Seite nach dem Laden offline (Flugmodus). Die laufend aktualisierte „Now“-Anzeige nutzt deine lokale Uhr, keine Netzwerk-Zeitquelle.

Häufige Fragen

Was ist ein Unix-Timestamp?

Ein Unix-Timestamp (auch Epoch-Zeit oder POSIX-Zeit genannt) ist die Anzahl der Sekunden seit dem 1. Januar 1970 um 00:00:00 UTC, gemäß Unix' POSIX-Abstraktion (die Schaltsekunden nicht zählt) statt echter, vergangener Atomuhr-Sekunden. Viele moderne Systeme nutzen für Sub-Sekunden-Präzision Millisekunden statt Sekunden (JavaScripts Date.now(), Javas System.currentTimeMillis(), .NETs DateTimeOffset.ToUnixTimeMilliseconds()). Unix-Zeit ist die Standard-Zeitdarstellung in praktisch jedem Betriebssystem, jeder Datenbank und jeder Web-API.

Was ist der Unterschied zwischen Sekunden und Millisekunden?

Ein Faktor 1.000. Sekunden-genaue Unix-Timestamps sind 2026 zehnstellig (z. B. 1714665600); millisekundengenaue dreizehnstellig (z. B. 1714665600234). Dieser Konverter erkennt automatisch anhand der Stellenzahl. Der häufigste Bug in Code, der beide Formen mischt, besteht darin, Millisekunden in eine Funktion zu füttern, die Sekunden erwartet (was ein Datum 1.000× weiter in der Zukunft als beabsichtigt ergibt) oder umgekehrt.

Warum ist meine konvertierte Uhrzeit um Stunden verschoben?

Unix-Zeit ist zeitzonenunabhängig, aber die menschenlesbare Form hängt davon ab, in welcher Zeitzone du sie anzeigst. Der Konverter zeigt drei Formate gleichzeitig: Lokalzeit (die Zeitzone deines Browsers), UTC (Greenwich) und ISO 8601 (mit explizitem Offset). Stimmt das Ergebnis nicht mit deiner Erwartung überein, prüfe die Zeitzone, dein „erwarteter“ Wert war wahrscheinlich in einer anderen Zeitzone als das Format, das du gelesen hast.

Was ist das Y2K38-Problem?

Wenn Unix-Zeit in einer vorzeichenbehafteten 32-Bit-Ganzzahl gespeichert wird (das ursprüngliche Unix-Design), läuft sie am 19. Januar 2038 um 03:14:07 UTC über. Moderne 64-Bit-Systeme sind nicht betroffen, das Überlaufdatum verschiebt sich auf etwa das Jahr 292 Milliarden. Das Y2K38-Risiko konzentriert sich auf weiterhin eingesetzte 32-Bit-Embedded-Systeme (Industriesteuerungen, Satelliten, Auto-Infotainment, Bank-Backends, IoT-Sensoren mit Jahrzehnte-Lebensdauer). Anders als Y2K wird das Y2K38-Problem keine Eintageskrise, sondern eine Serie kleiner Ausfälle in Long-Tail-Systemen über die Jahre bis 2038.

Funktioniert es offline?

Ja, sobald die Seite geladen ist, läuft die gesamte Umrechnung in deinem Browser über JavaScripts eingebaute Date-API. Während der Nutzung keine Netzwerkaufrufe. Der „Now“-Button nutzt die lokale Uhr deines Geräts; der laufend aktualisierte Timestamp oben aktualisiert sich aus deiner Systemuhr, ohne einen Zeitserver zu kontaktieren.

Verwandte Tools