Kostenloser Unix-Zeitstempel-Konverter

Was ist ein Unix-Zeitstempel?

Ein Unix-Zeitstempel (auch Epoch-Zeit oder POSIX-Zeit genannt) ist die Anzahl der Sekunden, die seit dem 1. Januar 1970, 00:00:00 UTC verstrichen sind. Es handelt sich um eine einfache, zeitzonenunabhängige Möglichkeit, einen Zeitpunkt darzustellen, und er wird häufig in der Programmierung, in Datenbanken, APIs und Serverprotokollen verwendet.

Zum Beispiel steht der Zeitstempel 1700000000 für den 14. November 2023 um 22:13:20 UTC. JavaScript verwendet Millisekunden-Zeitstempel (mit 1000 multiplizieren), während die meisten anderen Sprachen und APIs Sekunden nutzen.

Häufig gestellte Fragen

Welche Datumsformate kann ich eingeben?

Sie können Daten in den meisten Standardformaten eingeben: ISO 8601 (2025-12-31T23:59:59Z), gängige Datumszeichenfolgen (Dec 31, 2025 11:59 PM) oder einfache Formate wie 2025-12-31 23:59:59. Der Konverter verwendet den integrierten Datumsparser Ihres Browsers.

Erkennt er automatisch Sekunden vs. Millisekunden?

Ja. Wenn der Zeitstempel größer als 1 Billion ist, behandelt der Konverter ihn als Millisekunden. Andernfalls behandelt er ihn als Sekunden. Beide Formate werden in der Ergebnistabelle angezeigt.

Was ist das Jahr-2038-Problem?

Systeme, die Unix-Zeitstempel als vorzeichenbehaftete 32-Bit-Ganzzahlen speichern, laufen am 19. Januar 2038 um 03:14:07 UTC über. Moderne Systeme verwenden 64-Bit-Ganzzahlen, die Daten Milliarden von Jahren in der Zukunft darstellen können. Dieses Tool verwendet den Number-Typ von JavaScript, der Zeitstempel weit über 2038 hinaus verarbeiten kann.

Warum 1. Januar 1970?

Ein Unix-Timestamp ist eine ganzzahlige Zählung der seit der Unix-Epoche, 00:00:00 UTC am Donnerstag, dem 1. Januar 1970, vergangenen Sekunden. Es ist ein einzelner Skalar, der einen Moment in der Zeit eindeutig benennt, kalender- und zeitzonen-agnostisch: dieselbe Zahl benennt denselben Augenblick, ob Sie in Tokio oder Toronto sind.

Die Wahl von 1970 war etwas willkürlich, aber nicht zufällig. Die erste Auflage des UNIX Programmer's Manual (November 1971) definierte Systemzeit als Zahl der 60-Hz-Clock-Ticks seit 1971-01-01. Mit einem vorzeichenlosen 32-Bit-Integer, der bei 60 Hz zählt, hätte das System nur etwa 2,26 Jahre vor dem Überlauf abgedeckt, ein Problem, das schnell offensichtlich wurde. Bei der Vorbereitung der zweiten Auflage 1972 wechselte Ken Thompsons und Dennis Ritchies Team zum Zählen von Sekunden seit 1970-01-01: signierte 32-Bit-Integer, die Sekunden zählen, würden etwa 68 Jahre durchhalten, bequem über das Arbeitsleben der Code-schreibenden Ingenieure hinaus, und das jüngste Neujahr vor Projektbeginn machte die Arithmetik einfach. Es gab keine Komitee-Abstimmung und keinen IANA-artigen Standardisierungsprozess. Die Wahl blieb, weil Unix damit ausgeliefert wurde, und sobald hundert Millionen Maschinen ab diesem Moment zählten, war kein Ersatz mehr machbar.

POSIX (1988) kodifizierte die 1970er Epoche als IEEE Std 1003.1's „Seconds Since the Epoch." Heute untermauert dieselbe Epoche C/C++ time_t, Python time.time(), Ruby Time.now.to_i, JavaScript und Java (in Millisekunden, siehe unten), Linux/macOS-Dateisystem-Zeitstempel, Bitcoin- und Ethereum-Block-Header sowie JWT-iat/exp/nbf-Claims. Eine Handvoll Systeme verwenden versetzte Epochen (Windows FILETIME zählt 100-Nanosekunden-Ticks seit 1601-01-01, .NET DateTime Ticks seit 0001-01-01), aber Unix-Zeit ist die Lingua franca für alles, was eine OS- oder Sprachgrenze überquert.

Sekunden vs Millisekunden, der häufigste Bug

POSIX definiert den Timestamp als Sekunden seit der Epoche. Jede C-Bibliothek, jeder Python-Interpreter, jede Ruby/Go/Rust/Elixir-Laufzeit liefert Sekunden. JavaScript ist die berühmte Ausnahme, Date.now() und new Date().getTime() liefern Millisekunden. Javas System.currentTimeMillis() folgt der gleichen Konvention, und mehrere neuere Datenbanksysteme (etwa MongoDB BSONs Date-Typ) speichern ebenfalls Millisekunden.

Resultat: ein dauerhafter sprachübergreifender Bug. Ein Go-Backend schreibt 1700000000 (Sekunden) in ein JSON-Feld; ein Node.js-Client übergibt das an new Date(1700000000), aber JavaScript erwartet Millisekunden, also ist das resultierende Datum 1970-01-20 statt Ende 2023. Die Korrektur ist new Date(1700000000 * 1000). Umgekehrt: einen JS-Millisekunden-Timestamp in Pythons datetime.fromtimestamp() einzuspeisen, ergibt das Jahr ~55895. Stack Overflow hat Dutzende Varianten der Frage „JavaScript Date showing 1970", und das Mismatch ist in der großen Mehrheit die Wurzel.

Dieser Konverter implementiert eine Heuristik: wenn die Eingabe größer ist als 1.000.000.000.000, behandle sie als Millisekunden; sonst als Sekunden. Das funktioniert, weil 1e12 Sekunden das Jahr 33658 n. Chr. wäre (weit jenseits jeder realen Sekunden-Eingabe), während 1e12 Millisekunden der 9. September 2001 UTC ist (innerhalb des modernen Bereichs). Mikrosekunden- und Nanosekunden-Timestamps, die in einigen wissenschaftlichen Systemen und Linux-Kernel-APIs verwendet werden, würden die Schwelle nach oben drücken, für die müssen Sie die Präzision explizit angeben.

Das Jahr-2038-Problem („Y2K38")

Ein vorzeichenbehafteter 32-Bit-Integer kann Werte von −2.147.483.648 bis +2.147.483.647 speichern. Interpretiert als Sekunden seit 1970-01-01 UTC ist der maximal darstellbare Moment 03:14:07 UTC am Dienstag, 19. Januar 2038. Eine Sekunde später läuft der Zähler über und springt zum negativsten Wert, der als 20:45:52 UTC am Freitag, 13. Dezember 1901 dekodiert wird. Jedes 32-Bit-breite time_t, jede Datenbankspalte, die einen 4-Byte-Signed-Integer für Zeit speichert, und jedes Embedded-System, dessen Firmware vor etwa 2010 geschrieben wurde, ist gefährdet.

Die exponierte Fläche ist unbequem: industrielle PLCs und SCADA-Steuerungen mit 15-30-jährigen Einsatzzyklen, die heute installiert werden; ältere MySQL TIMESTAMP-Spalten, die dokumentiert an der 2038-Grenze sättigen; ext3-Dateisysteme; binäre Protokollformate (DNSSEC-RRSIG-Felder, NTPv3, mehrere industrielle Feldbusse), die einen 4-Byte-Timestamp packen; Smart-TVs und Automotive-Infotainment, die still und leise ältere 32-Bit-Linux-Kernel betreiben. Die gängige Korrektur ist die Erweiterung von time_t auf 64 Bit, was das Maximum auf etwa +292 Milliarden Jahre verlängert, jenseits des Wärmetods der Sonne. Linux 5.6 (März 2020) fügte 64-Bit-Zeit-Syscalls zu allen 32-Bit-Architekturen via Arnd Bergmanns y2038-Patchset hinzu; glibc 2.34 (August 2021) machte 64-Bit-time_t opt-in via _TIME_BITS=64; Debian 13 „Trixie" (2025) ist das erste Release mit dem vollständig neukompilierten Archiv. Apple deprecated 32-Bit-Binaries in macOS 10.15 (2019) und iOS 11 (2017), sodass die Verbraucher-Flotte effektiv immun ist.

Die verbleibende Risikofläche ist überwiegend embedded und Legacy-Daten auf der Platte: ein 64-Bit-Kernel, der eine 32-Bit-Timestamp-Spalte aus einer Legacy-Datenbank liest, ist genauso kaputt wie die Datenbank selbst. Migration ist ein Datenformat-Problem pro Anwendung, nicht nur ein Kernel-Problem.

JavaScript Date, die am meisten verfluchte API des Feldes

JavaScripts Date-Objekt wurde im Mai 1995 während des 10-Tage-Sprints, in dem Brendan Eich das originale LiveScript schrieb, wholesale aus Java 1.0 kopiert. Java selbst deprecated die meisten Methoden von java.util.Date in JDK 1.1 (1997), aber JavaScript erbte sie und konnte die Web-Kompatibilität nicht brechen, also bleiben sie. Das Ergebnis ist eine API, in der:

• Monate sind 0-indiziert (new Date(2024, 0, 15) = 15. Januar), Tage aber 1-indiziert.
• getYear() liefert „Jahr minus 1900", getYear() für 2024 ist 124. getFullYear() wurde später hinzugefügt, um 2024 direkt zu liefern.
• Date.parse('2024-03-15') wird als UTC-Mitternacht geparst; Date.parse('2024/03/15') ist lokale Mitternacht; Date.parse('March 15, 2024') ist implementierungsdefiniert.
• Vor ECMAScript 5 (Dezember 2009) war das Parsing fast vollständig implementierungsdefiniert, dieselbe Eingabezeichenkette konnte über IE, Firefox, Chrome und Safari verschiedene Date-Werte liefern.

Die Temporal-API (TC39 Stage 3 seit März 2021) ist der moderne Ersatz und bietet Temporal.Instant, Temporal.PlainDate, Temporal.PlainTime, Temporal.ZonedDateTime sowie einen echten Temporal.Duration-Typ. Browser-Unterstützung wird ausgerollt (Firefox Nightly, Safari 18 partiell, Chrome hinter einem Flag, Stand 2024); Polyfills funktionieren, fügen aber ~25 KB hinzu. Moment.js wurde im September 2020 von seinen Maintainern in den Wartungsmodus versetzt, für neue Projekte 2026 lautet die Empfehlung Temporal-first, wenn Browser-Support erlaubt, Luxon oder date-fns sonst, und Moment.js niemals.

Wann Sie dazu greifen

• API-Antworten debuggen. Die meisten JSON-APIs liefern Timestamps als Unix-Integer oder ISO-8601-Strings, und viele mischen. Dutzendmal am Tag eine Zahl in einen Konverter zu kleben ist der volumenstärkste Anwendungsfall.
• Log-Datei-Analyse. syslog, journald, AWS CloudWatch und die meisten Anwendungslogs sind in Unix-Sekunden gestempelt. Ingenieure kopieren einen Timestamp aus einer Log-Zeile und brauchen das Wanduhr-Äquivalent.
• Datenbank-Datumsspalten-Inspektion. Eine einmalige psql- oder mysql-Abfrage liefert 1700000000; die Datenbank hat Funktionen wie FROM_UNIXTIME(), aber ein Browser-Tool ist für ad-hoc-Arbeit schneller.
• JWT-Inspektion. Beim Dekodieren eines OAuth-Tokens steht "exp": 1738367200. Ist dieses Token abgelaufen? Wann läuft es ab? Ein Timestamp-Konverter ist die schnellste Antwort.
• Blockchain-Timestamps. Bitcoins Block-nTime ist in Unix-Sekunden (Überlauf 2106, 4-Byte unsigned). Ethereum-Block-Timestamps ebenfalls in Unix-Sekunden.
• OS-Dateisystem-Metadaten. ls -l --time-style=+%s druckt Unix-mtimes; stat -c '%Y' filename liefert mtime als Integer. Forensische Timestamp-Abgleichung beinhaltet oft manuelles Dekodieren.
• Zertifikat notBefore / notAfter und HTTP-If-Modified-Since-Header, alles Timestamps, die gelegentlich dekodiert werden müssen.

Eine Anmerkung zu Schaltsekunden

Seit 1972 wurden 27 Schaltsekunden in UTC eingefügt, um die Wanduhrzeit mit der sich verlangsamenden Erdrotation in Einklang zu halten. Die jüngste war 31. Dezember 2016 23:59:60 UTC. Unix-Zeit kodiert keine Schaltsekunden, POSIX sagt explizit, dass ein Unix-Timestamp so tut, als hätte jeder Tag genau 86.400 Sekunden. Ältere Linux-Systeme „wiederholen" die letzte Sekunde; Google und AWS verwenden ein „Leap Smear", das die zusätzliche Sekunde über ein 24-Stunden-Fenster verteilt. So oder so liest Unix-Zeit in der Speicherung nie 23:59:60, und das Subtrahieren zweier Timestamps, die eine Schaltsekunde überspannen, liefert eine Antwort, die eine Sekunde kürzer ist als die echte verstrichene SI-Sekundenzeit. Für Anwendungscode ist das unsichtbar. Für astronomische oder Finanztrading-Software kann es zählen. Im November 2022 stimmte die 27. Generalkonferenz für Maß und Gewicht dafür, bis 2035 keine Schaltsekunden mehr einzufügen und sie durch eine viel größere periodische Anpassung zu ersetzen.

Schnellreferenz

Timestamp	UTC datetime	Note
0	1970-01-01 00:00:00	The epoch
1,000,000,000	2001-09-09 01:46:40	First "billion-second" milestone
1,234,567,890	2009-02-13 23:31:30	"Cool number" celebrated by some devs
1,700,000,000	2023-11-14 22:13:20
2,000,000,000	2033-05-18 03:33:20	"Two billionth second"
2,147,483,647	2038-01-19 03:14:07	Last second representable in signed 32-bit
4,294,967,295	2106-02-07 06:28:15	Last representable in unsigned 32-bit (Bitcoin's nTime limit)
9,999,999,999	2286-11-20 17:46:39	Last 10-digit timestamp

Weitere Fragen

Warum zeigt derselbe Timestamp auf der Maschine meines Freundes eine andere Uhrzeit?

Weil die zugrundeliegende Zahl in UTC ist, die Anzeige aber zur Ortszeit konvertiert. 1700000000 ist 22:13:20 UTC, aber 17:13:20 in New York und 06:13:20 am nächsten Tag in Sydney. Die Zahl ist dieselbe; nur das Rendering unterscheidet sich. Um Zeitzonen-Verwirrung auszuschließen, bitten Sie beide Maschinen, in UTC anzuzeigen.

Was ist der Unterschied zwischen Y2K und Y2K38?

Y2K (Jahr 2000) war ein Logikproblem im Anwendungscode: viele Systeme speicherten Jahre als zwei ASCII-Ziffern, also wurde „00" mehrdeutig zwischen 1900 und 2000. Jede Anwendung musste einzeln inspiziert und gepatcht werden; die weltweiten Gesamt-Sanierungsausgaben wurden auf 300-600 Milliarden Dollar geschätzt. Y2K38 ist überwiegend ein Datentyp-Problem in Low-Level-Bibliotheken, das Neukompilieren der C-Bibliothek und des Kernels gegen 64-Bit-time_t behebt einen riesigen Teil der Fläche für jede Anwendung, die dagegen linkt. Die verbleibenden harten Fälle sind persistierte Plattendaten (Datenbanken, Datei-Metadaten, binäre Protokolle), die Datenmigrations-Tooling brauchen. Die konventionelle Weisheit ist, dass 2038 ein kleineres, weniger schlagzeilenträchtiges Ereignis als 2000 sein wird, mehr lokalisierte Embedded-Device-Ausfälle, weniger Schlagzeilen-Ausfälle.

Warum zeigt new Date('2024-03-15') manchmal den 14. März?

Weil dieser String nach ES5-Standard als UTC-Mitternacht geparst und dann in Ihrer lokalen Zeitzone angezeigt wird. In einer UTC-8-Zone wie US Pacific ist UTC-Mitternacht am 15. März 16 Uhr am 14. März Ortszeit, also liefert .getDate() 14. Die Korrektur in modernem Code ist entweder new Date('2024-03-15T12:00:00') (was JavaScript als lokalen Mittag interpretiert, wenn Sie das Z weglassen) oder, besser, die Temporal.PlainDate.from()-API, sobald sie ausgeliefert wird.

Wird etwas an einen Server gesendet?

Nein. Die Konvertierung ist JavaScript-Arithmetik, die lokal in Ihrem Browser läuft. Nichts über die von Ihnen eingegebenen Timestamps verlässt die Seite, nützlich, wenn die Werte Kunden-IDs, interne Log-Zeilen oder Sitzungs-Debug-Daten sind, die Sie lieber nirgendwohin hochladen möchten. Die Seite funktioniert offline, sobald sie geladen ist.

Verwandte Werkzeuge