Zeitstempel-Konverter: Unix-Zeit, ISO 8601 und Zeitzonen sicher umrechnen

In Logdateien, Datenbankfeldern, JSON-Antworten von APIs und Zertifikaten stecken Zeitpunkte oft als nackte Zahl: 1790769600, 1790769600000 oder noch länger. Wer bei einer Störung wissen will, wann genau ein Fehler auftrat, muss diese Werte schnell und richtig in Ortszeit übersetzen, und zwar auch an den Tagen der Zeitumstellung. Der Zeitstempel-Konverter auf s-edv.com/tools/timestamp erkennt Unix-Zeitstempel in Sekunden bis Nanosekunden, ISO 8601, RFC 2822 und deutsche Datumsangaben und rechnet sie in alle Richtungen und Zeitzonen um. Diese Anleitung richtet sich an Administratoren und Entwickler in kleinen und mittleren Unternehmen. Sie zeigt jede Funktion so, wie sie im Browser tatsächlich arbeitet, erklärt die Fallstricke rund um Epoche, Zeitzonen und Kalenderwochen und wie Sie jedes Ergebnis mit date im Terminal gegenprüfen.

Voraussetzungen

• Einen aktuellen Browser mit JavaScript. Die Ortszeit richtet sich nach der Zeitzone Ihres Rechners; prüfen Sie, dass sie stimmt.
• Für die Gegenprobe ein Linux-Terminal mit GNU date (in coreutils enthalten) oder unter macOS date -r. Optional Python 3.
• Zugriff auf die Quelle der Zeitstempel, etwa journalctl, Logdateien, eine Datenbank oder API-Antworten.
• Grundwissen zu UTC und Sommerzeit: In Deutschland gilt im Winter MEZ (UTC+1), im Sommer MESZ (UTC+2).

Kurz zur Grundlage: Ein Unix-Zeitstempel zählt die Sekunden seit dem 1. Januar 1970, 00:00:00 Uhr UTC, der sogenannten Epoche. Die Zahl enthält keine Zeitzone und bezeichnet weltweit denselben Augenblick; date +%s liefert in Berlin und Tokio im selben Moment denselben Wert. Erst bei der Anzeige als Datum kommt eine Zeitzone ins Spiel. Schaltsekunden kennt die Unix-Zeit nicht, jeder Tag hat genau 86 400 Sekunden. Werte vor 1970 sind negativ.

Schritt 1: Tool öffnen und aktuelle Zeit ablesen

Öffnen Sie s-edv.com/tools/timestamp. Oben stehen „Läuft komplett in Ihrem Browser“, „Keine Daten an einen Server“ und „Ohne Anmeldung, ohne Tracking“. Der Kasten „Jetzt“ zeigt Ihre Zeitzone (etwa „Europe/Berlin“) und laufend „UNIX-SEKUNDEN“, „UNIX-MILLISEKUNDEN“ und „ORTSZEIT“. Beide Zahlen lassen sich über die Kopierknöpfe direkt übernehmen, etwa für ein Skript oder einen API-Test. „Jetzt umrechnen“ setzt die aktuelle Zeit in das Eingabefeld.

Verifizieren: Vergleichen Sie „UNIX-SEKUNDEN“ mit Ihrem Server. Die Werte dürfen höchstens wenige Sekunden auseinanderliegen; größere Abweichungen deuten auf eine falsch gehende Uhr hin.

date +%s
timedatectl | grep -i synchronized

Schritt 2: Zeitstempel in ein Datum umrechnen

Fügen Sie den Wert unter „Umrechnen“ in das Feld „Zeitstempel oder Datum“ ein. Das Tool rechnet ohne Klick. Unter „Erkannt:“ steht das Format, zum Beispiel „Unix-Zeitstempel in Sekunden (10 Stellen)“. Die Einheit bestimmt das Tool bei „Automatisch“ an der Stellenzahl:

Einheit	Stellen heute	Typische Quelle
Sekunden	10	Shell, PHP time(), viele Datenbanken
Millisekunden	13	JavaScript Date.now(), Java
Mikrosekunden	16	manche Datenbanken, Tracing
Nanosekunden	19	Go UnixNano(), Python time.time_ns(), Grafana Loki

Im Test ergaben 1790769600, 1790769600000, die 16- und die 19-stellige Variante sowie @1790769600 jeweils denselben Zeitpunkt. Nachkommastellen wie 1790769600.5 erscheinen als 2026-09-30T12:00:00.500Z. Wenn die Automatik falsch liegt, stellen Sie die Einheit über „s“, „ms“, „µs“ oder „ns“ fest ein. Das Tool rechnet dann stur in dieser Einheit; ein 13-stelliger Wert als Sekunden gelesen landet im Jahr 58717, ein deutliches Zeichen für die falsche Einheit.

Unter „Ergebnis“ stehen „Unix (Sekunden)“, „Unix (Millisekunden)“, „ISO 8601 (UTC)“, „ISO 8601 (Ortszeit)“ mit Zone und Kürzel (MESZ oder MEZ), „RFC 2822“ für E-Mail-Header und HTTP, „Deutsches Format“, „Wochentag“, „Kalenderwoche“ samt ISO-Schreibweise wie 2026-W40-3, „Tag im Jahr“, „Relativ“ (etwa „vor 15 Stunden“) und „Schaltjahr“. Jede Zeile hat einen Kopierknopf.

Verifizieren: GNU date liefert dieselben Werte. Für 1790769600 zeigt das Tool 2026-09-30T12:00:00Z und in Berlin Mittwoch, 14:00 Uhr, KW 40:

date -u -d @1790769600 +%FT%TZ
# 2026-09-30T12:00:00Z
TZ=Europe/Berlin date -d @1790769600 '+%a %F %T %z KW%V %G-W%V-%u'
# Mi 2026-09-30 14:00:00 +0200 KW40 2026-W40-3
TZ=Europe/Berlin date -R -d @1790769600
# Wed, 30 Sep 2026 14:00:00 +0200

Schritt 3: Datumsangaben und Header-Zeiten einlesen

Dasselbe Feld nimmt auch lesbare Angaben an. Das Tool erkannte im Test:

• ISO 8601 mit Versatz wie 2026-09-30T14:00:00+02:00 („ISO 8601 mit Zeitversatz UTC+02:00“)
• ISO 8601 ohne Zone wie 2026-09-30T14:00 („als Ortszeit Ihres Browsers gedeutet“) und reines Datum, das als 00:00 Uhr Ortszeit gilt
• RFC 2822 aus Mail- und HTTP-Headern, etwa Wed, 30 Sep 2026 12:00:00 GMT
• deutsche Angaben wie 30.09.2026 14:00 und kurze Formen wie 30.9.26; bei zweistelligen Jahren erscheint der Hinweis, dass 00 bis 68 als 2000er und 69 bis 99 als 1900er gelten
• Kalenderwochen wie 2026-W40-3 (Mittwoch der KW 40, 00:00 Uhr Ortszeit)

Die Vorlagen unter dem Feld („Jetzt“, „1790769600“, „1790769600000 ms“, „ISO 8601“, „RFC 2822“, „30.09.2026 14:00“, „KW 40“, „negativ“, „2038-Grenze“) füllen passende Beispiele ein. Praxisfall: Ein Webserver meldet im Header Last-Modified eine GMT-Zeit; eingefügt sehen Sie sofort die Berliner Ortszeit und den Unix-Wert für einen Abgleich mit dem Log.

Die Eingabe steht im Adress-Anker hinter dem #, etwa #t=1790769600000. So können Sie einem Kollegen einen Link zum Ergebnis schicken. Der Teil hinter # wird nicht an den Server gesendet.

Verifizieren: Rechnen Sie die Gegenrichtung mit date nach. Beide Befehle müssen 1790769600 ausgeben:

date -d 'Wed, 30 Sep 2026 12:00:00 GMT' +%s
TZ=Europe/Berlin date -d '2026-09-30 14:00' +%s

Schritt 4: Zeitzonen vergleichen

Die Tabelle „Zeitzonen“ zeigt den eingegebenen Moment in Berlin (mit „Ihre Zone“), UTC, London, New York, Los Angeles, Tokio und Sydney, jeweils mit Datum, Uhrzeit und Versatz wie „UTC-04:00“. Unter „Weitere Zeitzone“ wählen Sie aus über 400 Zonen eine zusätzliche aus, sie erscheint als „Eigene Auswahl“. Diese Wahl merkt sich der Browser lokal, laut Seite als einzige gespeicherte Angabe; im Test stand sie im Local Storage unter sedv.tools.ts.zone. Die Zone Indien heißt in der Liste übrigens noch „Asia/Calcutta“.

Praxisfall: Ein Dienstleister in New York meldet einen Ausfall um 08:00 Uhr Ortszeit. Geben Sie 2026-09-30T08:00:00-04:00 ein und lesen Sie in der Berlin-Zeile 14:00 Uhr ab; so finden Sie die passenden Einträge in Ihrem eigenen Log.

Verifizieren: Prüfen Sie einzelne Zeilen mit der Variable TZ:

TZ=America/New_York date -d @1790769600 '+%F %T %z'
# 2026-09-30 08:00:00 -0400
TZ=Asia/Kolkata date -d @1790769600 '+%F %T %z'
# 2026-09-30 17:30:00 +0530

Schritt 5: Datum in einen Zeitstempel umrechnen

Für die Gegenrichtung gibt es unten den Bereich „Datum → Zeitstempel“. Wählen Sie „Browser-Zeitzone“ oder „UTC“ und tragen Sie unter „Datum und Uhrzeit“ den Zeitpunkt ein. Das Tool zeigt „Unix (Sekunden)“, „Unix (Millisekunden)“ und „ISO 8601 (UTC)“. Im Test ergab 30.09.2026, 14:00 Uhr in Browser-Zeitzone 1790769600, dieselbe Eingabe in UTC 1790776800, zwei Stunden später. „Oben übernehmen“ setzt den Wert in das Hauptfeld, damit Sie alle Formate und Zonen sehen. Das Eingabefeld nimmt Minuten an; für sekundengenaue Werte nutzen Sie das obere Feld.

Typischer Einsatz: Sie wollen Logs ab einem bestimmten Zeitpunkt filtern oder eine API mit einem Zeitfenster abfragen.

Verifizieren: journalctl akzeptiert Unix-Zeitstempel mit vorangestelltem @. Die Ausgabe muss mit Einträgen ab 14:00 Uhr Berliner Zeit beginnen:

journalctl --since @1790769600 --until @1790773200 --no-pager | head
date -u -d '2026-09-30 14:00' +%s
# 1790776800

Typische Fehler

• Falsche Einheit: Ein Datum im Januar 1970 oder in ferner Zukunft heißt fast immer Millisekunden statt Sekunden oder umgekehrt. Einheit fest einstellen.
• Stunde verrutscht: Server protokollieren oft in UTC. Ortszeit liegt im Winter eine, im Sommer zwei Stunden davor. In der Tabelle „Zeitzonen“ die UTC-Zeile mit Berlin vergleichen.
• Eingabe ohne Zeitzone: 2026-09-30T14:00 gilt als Ortszeit Ihres Browsers. Stammt der Wert von einem UTC-Server, hängen Sie Z an.
• Zeitumstellung: Bei 29.03.2026 02:30 meldet das Tool, dass es diese Ortszeit nicht gibt, und verwendet die Zeit nach der Umstellung (03:30 MESZ). Bei 25.10.2026 02:30 kommt die Zeit zweimal vor; das Tool nimmt den ersten Zeitpunkt, noch in Sommerzeit. GNU date verhält sich im Test genauso.
• „Format nicht erkannt.“: Erscheint bei Freitext; die Meldung nennt Beispiele für gültige Formate.
• Ungültiges Datum: 31.02.2026 ergibt „Den 31. gibt es in diesem Monat nicht (02/2026 hat 28 Tage).“
• Jahr-2038-Problem: Ab 2147483648 warnt das Tool, dass der Wert nicht in einen vorzeichenbehafteten 32-Bit-Zähler passt. Betroffen sind alte Embedded-Geräte, Dateiformate und Felder wie TIMESTAMP in MySQL.
• Kalenderwoche am Jahreswechsel: Der 1. Januar 2027 gehört nach ISO 8601 zu KW 53 des Jahres 2026, das Tool zeigt „KW 53 (2026)“. Wer mit US-Zählweisen arbeitet, kommt auf andere Wochen.

Häufige Fragen

Woran erkenne ich Sekunden und Millisekunden?

An der Länge: Aktuelle Zeitpunkte haben in Sekunden 10 Stellen, in Millisekunden 13. Zehnstellige Sekundenwerte reichen vom 9. September 2001 bis zum 20. November 2286.

Werden meine Eingaben übertragen?

Laut Seite nein, die Umrechnung läuft im Browser. Die Eingabe steht im Anker hinter #, der nicht an den Server geht, und die zusätzliche Zone im lokalen Browserspeicher. Im Test lud die Seite während der Eingaben keine weiteren Ressourcen nach.

Warum beginnt die Kalenderwoche nicht immer im Januar?

Nach ISO 8601 beginnt die Woche am Montag, und KW 1 ist die Woche mit dem ersten Donnerstag des Jahres, also immer die Woche mit dem 4. Januar. Deshalb hat 2026 eine KW 53.

Wie plane ich Cronjobs über die Zeitumstellung?

Jobs zwischen 02:00 und 03:00 Uhr laufen an den Umstellungstagen nicht oder doppelt. Hintergründe stehen in der Anleitung Cron und crontab richtig nutzen; Termine prüfen Sie mit dem Cron-Tester.

Testumfang

Das Tool wurde am 1. Oktober 2026 in einem aktuellen Chromium mit Zeitstempeln in allen vier Einheiten, negativen Werten, der 2038-Grenze, ISO-, RFC-2822- und deutschen Angaben, Kalenderwochen, beiden Umstellungstagen 2026 und Fehleingaben ausprobiert. Alle Unix-Werte, UTC- und Berliner Zeiten, Wochentage und Kalenderwochen stimmten mit GNU date und dem Python-Modul datetime überein, auch beim Jahreswechsel 2026/2027.

Fazit

Der Zeitstempel-Konverter nimmt nahezu jedes Zeitformat aus Logs, Headern und APIs an und zeigt das Ergebnis in allen gängigen Schreibweisen und Zonen auf einen Blick. Besonders hilfreich sind die ehrlichen Hinweise auf mehrdeutige Eingaben ohne Zeitzone, auf Lücken und Doppelungen bei der Zeitumstellung und auf die 2038-Grenze. Wer die Einheit im Blick behält und bei Serverwerten an UTC denkt, spart sich bei der Fehlersuche viele Kopfrechnungen. Für Skripte bleibt date der verlässliche Gegencheck. Wie Sie Logs gezielt nach Zeitfenstern durchsuchen, zeigt Logs lesen mit journalctl und /var/log.

Weiterführende Anleitungen und Quellen

• Logs lesen mit journalctl und /var/log
• Logs zentralisieren mit Grafana Loki
• Cron und crontab richtig nutzen: die Grundlagen
• RFC 3339: Date and Time on the Internet (Profil von ISO 8601)
• RFC 2822, Abschnitt 3.3: Date and Time Specification
• man-page date(1)
• systemd.time(7): Zeitangaben für journalctl und Timer