Unix-Timestamp-Konverter
Zeitstempel eingeben und sofort sehen, welches Datum dahintersteckt – oder umgekehrt aus Datum und Uhrzeit den passenden Epoch-Wert erzeugen. Sekunden, Millisekunden, Mikrosekunden und Nanosekunden werden automatisch erkannt, die Zeitzone ist frei wählbar. Alles lokal in deinem Browser.
Aktueller Unix-Zeitstempel
–––Umgerechnet
| Gewählte Zeitzone | – | |
|---|---|---|
| Deine Ortszeit | – | |
| UTC | – | |
| ISO 8601 / RFC 3339 | – | |
| ISO 8601 (UTC) | – | |
| RFC 7231 (HTTP-Datum) | – | |
| Relativ zu jetzt | – | |
| Wochentag, KW, Tag des Jahres | – | |
| Sekunden | – | |
| Millisekunden | – | |
| Mikrosekunden | – | |
| Nanosekunden | – |
Alles läuft lokal in deinem Browser – nichts wird hochgeladen.
Was ist ein Unix-Zeitstempel?
Ein Unix-Zeitstempel (auch Epoch-Zeit oder POSIX-Zeit) zählt die Sekunden, die seit dem 1. Januar 1970 um 00:00:00 UTC vergangen sind – dem sogenanntenUnix-Epoch. Weil es sich um eine einzelne ganze Zahl handelt, ist der Wert unabhängig von Zeitzone, Sommerzeit, Kalenderformat und Sprache. Genau deshalb speichern Datenbanken, Logdateien, APIs und Dateisysteme Zeitpunkte fast immer so und rechnen erst bei der Ausgabe in ein lesbares Datum um.
Ein Detail, das oft übersehen wird: Die Unix-Zeit ignoriert Schaltsekunden. Jeder Tag zählt exakt 86.400 Sekunden, auch wenn die Erdrotation gelegentlich eine Zusatzsekunde nötig macht. Der Zeitstempel misst also streng genommen nicht die tatsächlich verstrichene physikalische Zeit, sondern eine idealisierte Tageszählung – für Anwendungen im Alltag ist das genau das gewünschte Verhalten.
Sekunden, Millisekunden, Mikrosekunden oder Nanosekunden?
Dieselbe Zahl bedeutet je nach Einheit ein völlig anderes Datum. Weil sich die Einheit an der Stellenzahl ablesen lässt, erkennt dieses Werkzeug sie automatisch – und zeigt an, wofür es sich entschieden hat:
| Einheit | Stellen heute | Typisch für |
|---|---|---|
| Sekunden | 10 | Unix/POSIX, date +%s, JWT-Claims, Cron, PHP time() |
| Millisekunden | 13 | JavaScript Date.now(), Java currentTimeMillis(), Kafka |
| Mikrosekunden | 16 | Python time.time_ns()/1000, PostgreSQL-Interna, ClickHouse |
| Nanosekunden | 19 | Go UnixNano(), InfluxDB, Prometheus-Interna, Tracing |
Der klassische Fehler: Ein Millisekunden-Wert wird als Sekunden interpretiert und landet dann im Jahr 56.000 – oder ein Sekunden-Wert als Millisekunden und zeigt den 20. Januar 1970. Wenn dir ein Datum unplausibel vorkommt, ist fast immer die Einheit die Ursache. Über das Auswahlfeld lässt sich die automatische Erkennung jederzeit überstimmen.
ISO 8601 und RFC 3339
2026-09-04T14:30:00+02:00 ist die Schreibweise, die praktisch alle modernen APIs verwenden. ISO 8601 ist die zugrundeliegende Norm, RFC 3339eine engere Auslegung davon für den Einsatz im Internet: Sie schreibt das T als Trennzeichen vor, verlangt zwingend eine Offset-Angabe und erlaubt keine der exotischeren ISO-Varianten wie Wochendaten (2026-W36-5) oder verkürzte Formen. Ein RFC-3339-Datum ist damit immer auch ein gültiges ISO-8601-Datum, umgekehrt gilt das nicht.
Das Z am Ende (2026-09-04T12:30:00Z) steht für Offset null, also UTC – gesprochen „Zulu“, aus dem NATO-Buchstabieralphabet. Wichtig ist der Unterschied zwischenOffset und Zeitzone: +02:00 ist nur ein Zahlenwert für diesen einen Zeitpunkt, Europe/Berlin dagegen eine Zone mit einer ganzen Historie von Umstellungsregeln. Aus einem Offset allein lässt sich die Zone nicht rekonstruieren.
Das Jahr-2038-Problem
Wird der Zeitstempel als vorzeichenbehaftete 32-Bit-Ganzzahl gespeichert, ist bei2.147.483.647 Schluss – das entspricht dem19. Januar 2038 um 03:14:07 UTC. Eine Sekunde später kippt der Wert ins Negative und das System landet im Dezember 1901. Betroffen sind vor allem ältere eingebettete Systeme, alte Dateiformate und 32-Bit-Builds; auf 64-Bit-Systemen reicht der Wertebereich rund 292 Milliarden Jahre. Wer heute noch time_t als int speichert, sollte das prüfen – 2038 ist näher als der Y2K-Abstand, den man dafür einmal hatte.
Negative Zeitstempel und Zeiten vor 1970
Daten vor dem Epoch werden als negative Zahl dargestellt: -86400 ist der 31. Dezember 1969. Das funktioniert hier vollständig, ist aber nicht überall selbstverständlich – manche Datenbanken und Bibliotheken lehnen negative Werte ab oder interpretieren sie als vorzeichenlose Zahl, was zu Daten im Jahr 2106 führt. Bei historischen Datumsangaben ist außerdem zu beachten, dass die IANA-Zeitzonendatenbank für viele Regionen erst ab dem späten 19. Jahrhundert verlässliche Offsets kennt.
Häufige Fragen
In welcher Zeitzone werden die Daten angezeigt?
In der oben gewählten. Voreingestellt ist die Zone deines Browsers, zusätzlich stehen UTC und alle Zonen der IANA-Datenbank zur Auswahl. Die Umrechnung berücksichtigt die Sommerzeit-Regeln des jeweiligen Zeitpunkts – ein Datum im Januar wird also anders umgerechnet als eines im Juli.
Warum unterscheidet sich mein Ergebnis um ein oder zwei Stunden?
Fast immer, weil ein Wert als Ortszeit gespeichert, aber als UTC gelesen wurde (oder umgekehrt). Der Zeitstempel selbst kennt keine Zeitzone – die Zone entsteht erst bei der Darstellung. Prüfe deshalb, in welcher Zone der Wert erzeugt wurde.
Was bedeutet die Kalenderwoche in der Ergebnisliste?
Die Kalenderwoche nach ISO 8601: Die Woche beginnt am Montag, und Woche 1 ist die Woche, die den ersten Donnerstag des Jahres enthält. Deshalb kann der 31. Dezember bereits in Woche 1 des Folgejahres liegen – das zugehörige Jahr wird darum mit angezeigt.
Werden meine Eingaben hochgeladen?
Nein. Die gesamte Umrechnung ist JavaScript in deinem Browser, die Zeitzonen-Daten bringt der Browser selbst mit. Es gibt keinen Server, der etwas entgegennehmen könnte. Gemerkt werden nur die gewählte Richtung, Einheit und Zeitzone.
Verwandt: Der JWT-Decoder zeigt die Claimsexp, iat und nbf als lesbares Datum, und derCron-Generator berechnet die nächsten Ausführungszeiten eines Zeitplans.