Unix Zeitstempel-Generator

Funktionsweise

1. Datum in Zeitstempel konvertieren: Geben Sie ein beliebiges Datum und eine Uhrzeit mit dem Datums-Picker ein, dann klicken Sie auf Konvertieren, um den Unix-Zeitstempel in Sekunden und Millisekunden zu erhalten.
2. Zeitstempel in Datum konvertieren: Fügen Sie einen Unix-Zeitstempel (Sekunden oder Millisekunden) ein, um ihn zurück in ein menschenlesbares Datum und eine Uhrzeit zu konvertieren.
3. Aktuellen Zeitstempel erhalten: Klicken Sie auf „Jetzt", um sofort den aktuellen Unix-Zeitstempel für den gegenwärtigen Moment zu erhalten.

Warum den Unix-Zeitstempel-Generator verwenden?

Unix-Zeitstempel sind die universelle Sprache der Zeit in der Informatik, eine einzige Ganzzahl, die Sekunden seit dem 1. Januar 1970 (UTC) repräsentiert. Sie treiben Datenbanken, APIs, Log-Dateien, Authentifizierungs-Tokens und Event-Planung an. Die manuelle Konvertierung zwischen Unix-Zeitstempeln und menschenlesbaren Daten beinhaltet komplexe Zeitzonen-Arithmetik, die leicht falsch zu machen ist. Dieses Tool behandelt die Konvertierung in beide Richtungen korrekt, spart Zeit und verhindert Zeitzonen-Bugs.

Funktionen

• Bidirektionale Konvertierung: Datum/Uhrzeit → Unix-Zeitstempel und Unix-Zeitstempel → Datum/Uhrzeit.
• Sekunden und Millisekunden: Unterstützt sowohl Unix-Zeit in Sekunden (10 Stellen) als auch Millisekunden (13 Stellen).
• Zeitzonen-Bewusstsein: Zeigt die Zeit in Ihrer lokalen Zeitzone und in UTC für eindeutigen Vergleich.
• Aktuelle-Zeit-Button: Sofort den Zeitstempel für den jetzigen Moment erhalten.
• Relative Zeitanzeige: Zeigt, wie lange her oder wie weit in der Zukunft ein Zeitstempel liegt (z. B. „vor 3 Tagen").

Häufig gestellte Fragen

Was ist ein Unix-Zeitstempel?

Ein Unix-Zeitstempel ist die Anzahl der Sekunden, die seit der Unix-Epoche verstrichen sind, Mitternacht UTC am 1. Januar 1970. Es ist eine zeitzonenunabhängige Darstellung eines Zeitpunkts, was es zum bevorzugten Format für die Speicherung und den Vergleich von Zeiten in Datenbanken und APIs macht.

Warum verwendet JavaScript Millisekunden?

JavaScripts Date.now() und new Date().getTime() liefern Millisekunden seit der Epoche (eine 13-stellige Zahl), während Unix-Tools und die meisten Datenbanken Sekunden verwenden (eine 10-stellige Zahl). Prüfen Sie, ob Ihr Zeitstempel 10 oder 13 Stellen hat, um zu bestimmen, welches Format Sie haben.

Wie konvertiere ich einen Zeitstempel in meine Lokalzeit?

Fügen Sie den Zeitstempel ein, und das Tool konvertiert ihn automatisch in die lokale Zeitzone Ihres Browsers. Die Anzeige zeigt sowohl Lokalzeit als auch UTC, sodass Sie über Zeitzonen hinweg sicher arbeiten können.

Woher Unix-Zeit kommt

Unix-Zeit wurde von Ken Thompson und Dennis Ritchie in Unix First Edition (November 1971) definiert. Anfänglich zählte der Kernel 60stel-Sekunden seit dem 1971-01-01 in einem 32-Bit-Feld, das nach 2 Jahren 9 Monaten überlief. Mit Unix Sixth Edition (1975) wurde die Zählung auf Sekunden seit 1970-01-01 00:00:00 UTC geändert, die Epoche, die jedes Unix-ähnliche System heute noch verwendet. Die Wahl war willkürlich, die Ingenieure brauchten ein rundes Datum nahe der Ära, in der sie arbeiteten. POSIX.1 (1988) kodifizierte die Definition als offiziellen Standard, und POSIX.1-2017 (IEEE Std 1003.1-2017), die aktuelle Version, definiert time_t immer noch als Anzahl der Sekunden seit der Epoche, mit der Einschränkung, dass POSIX-Zeit so tut, als ob Schaltsekunden nicht existieren. ISO 8601 (1988, derzeit 2019) standardisierte das lesbare Format 2026-05-13T14:30:00Z, und RFC 3339 (Juli 2002) verengte es zu einem eindeutigen Internet-Datum-Zeit-Profil. JavaScripts Date.now() gibt Millisekunden seit der Epoche zurück, weil die Spec 1995 geschrieben wurde, als Sub-Sekunden-Präzision bereits gefragt war; die meisten Datenbanken und Unix-Utilities verwenden immer noch ganze Sekunden.

Das Jahr-2038-Problem (und warum es jetzt wichtig ist)

Ein vorzeichenbehaftetes 32-Bit-time_t kann höchstens 2.147.483.647 Sekunden darstellen, die am Dienstag, 19. Januar 2038, 03:14:07 UTC eintreffen. Eine Sekunde später läuft der Zähler auf −2.147.483.648 um, was die meiste Software als 13. Dezember 1901 interpretiert. Es ist die gleiche Klasse von Bug wie Y2K, aber verursacht durch die Ganzzahl-Breite, nicht das Datumsformat. Die Lösung ist, 64-Bit-time_t zu verwenden (was den Überlauf auf etwa das Jahr 292 Milliarden schiebt). Die meisten 64-Bit-Linux-Systeme verwenden bereits standardmäßig 64-Bit-time_t; Linux 5.6 (März 2020) machte 64-Bit-time_t auch auf 32-Bit-Architekturen verfügbar. Das verbleibende Risiko lebt in eingebetteten Systemen, alten Binärdateiformaten und 32-Bit-Netzwerkprotokollen. Das Network Time Protocol (NTP) läuft bereits 2036 um, weil es einen vorzeichenlosen 32-Bit-Zähler seit 1900 verwendet, NTPv4 fügt eine Ära-Nummer hinzu, um es zu erweitern. Wenn du Software ausliefst, die Daten verarbeitet, prüfe deinen Stack vor 2038, besonders SQL-Spalten vom Typ INT(11) oder älteren C-Code mit long-Zeitfeldern.

Die Timestamp-Formate, denen du begegnen wirst

• Unix-Sekunden (10 Ziffern). 1747143000. Das klassische POSIX-time_t. Verwendet von PostgreSQL EXTRACT(epoch FROM ...), MySQL UNIX_TIMESTAMP(), Redis-TTLs, JWT-iat/exp-Claims (gemäß RFC 7519), git log und den meisten Unix-Utilities. Wird nach November 2286 11 Ziffern haben.
• Unix-Millisekunden (13 Ziffern). 1747143000000. JavaScripts Date.now(), Javas System.currentTimeMillis(), Kafka, Elasticsearch und die meisten modernen Logging-Pipelines. Mal 1000 die Sekundenzählung.
• Unix-Mikrosekunden (16 Ziffern) und Nanosekunden (19 Ziffern). 1747143000000000. Verwendet von Pythons time.time_ns(), Gos time.Now().UnixNano(), etcd-MVCC-Revisionen und Hochfrequenzhandelssystemen, wo Millisekundenauflösung zu grob ist.
• ISO 8601. 2026-05-13T14:30:00.000Z oder 2026-05-13T14:30:00+02:00. Als String sortierbar, eindeutig in Bezug auf Zeitzone, von praktisch jeder modernen API akzeptiert. Das Suffix Z bedeutet «Zulu-Zeit», eine NATO-Bezeichnung für UTC.
• RFC 3339. Ein strengeres Profil von ISO 8601, das von JSON Schema, OpenAPI und den meisten REST-APIs verwendet wird. Erfordert einen Zeitzonenbezeichner und verbietet einige ISO-8601-Funktionen wie Wochenangaben und ordinale Datumsangaben.
• RFC 2822 / RFC 5322. Tue, 13 May 2026 14:30:00 +0000. Das Format des E-Mail-Date:-Headers. Immer noch allgegenwärtig, weil SMTP überall läuft.
• Excel-Seriendatum. Bruchteile von Tagen seit 1900-01-01 (oder 1904 auf klassischem Mac Excel). 2026-05-13 14:30 ist ungefähr 46150.6042. Excel behandelt bekanntlich 1900 als Schaltjahr (ist es nicht) für Lotus-1-2-3-Kompatibilität.

Wann dieses Werkzeug seinen Wert beweist

• JWT-Debugging. Token hat "exp": 1747143000 und du musst wissen, ob es abgelaufen ist. Einfügen, menschliches Datum sehen.
• Log-Forensik. Eine Zeile sagt timestamp=1747143012345, du musst mit der Wanduhrzeit eines anderen Werkzeugs korrelieren. 13 Ziffern, also Millisekunden.
• Datenbankabfragen. Du willst Zeilen nach einem bestimmten Datum finden. WHERE created_at > 1747143000 benötigt den Sekundenwert; kopiere ihn aus dem Werkzeug.
• Testfixtures. «Gestern» in einem Test hartkodieren, du generierst den Timestamp jetzt und fügst ihn in die Spec ein.
• Cron / geplante Jobs. Überprüfe den Sekundenwert, zu dem ein Scheduler auslösen wird, besonders über DST-Übergänge.
• Event-Replay. Kafka-Offsets und Elasticsearch-Indizes verwenden oft Millisekunden-Timestamps; konvertiere in ein Datum, um ein bestimmtes Replay-Fenster zu inspizieren.
• Cache-Invalidierung. Ein Expires-Header oder If-Modified-Since im RFC-2822-Format, generiere das richtige Wire-Format zum Testen.

Fehler, die Teams Stunden kosten

• Sekunden und Millisekunden vermischen. Eine 10-stellige Wert an eine Funktion zu übergeben, die Millisekunden erwartet, gibt ein Datum in 1970 zurück, um einen Faktor 1000 verschoben. Die 10-vs-13-Ziffern-Regel ist der schnellste Test, moderne Werte in Sekunden haben 10 Ziffern bis 2286, in Millisekunden 13 Ziffern.
• Lokale Zeit speichern. Speichere immer UTC; konvertiere zur Anzeigezeit nach lokal. "2026-05-13 14:30:00" ohne Zeitzone zu speichern, bricht in dem Moment, in dem ein Server, Benutzer oder DST-Sprung den lokalen Offset ändert.
• DST-Übergänge vergessen. 2:30 Uhr passiert zweimal während des Rückfalls. Naiver Code, der start + (24 * 3600) tut, um «morgen» zu bedeuten, wird zweimal im Jahr um eine Stunde abweichen. Verwende eine echte Datumsbibliothek (luxon, date-fns-tz, Pythons zoneinfo), die die IANA-tz-Datenbank kennt.
• Annahme, dass POSIX-Zeit Schaltsekunden berücksichtigt. Tut sie nicht. 2016-12-31 23:59:60 existierte im echten Leben (die 27. Schaltsekunde), aber das POSIX-time_t springt von 23:59:59 zu 00:00:00 ohne Bewusstsein für die zusätzliche Sekunde. TAI (Internationale Atomzeit) zählt Schaltsekunden, POSIX-Zeit ist von UTC um null Sekunden verschoben.
• time_t in INT(4)-Spalten speichern. Alte MySQL-Schemata verwenden häufig INT, das 4 Byte / vorzeichenbehaftet 32 Bit / wickelt sich 2038 um. Migriere zu BIGINT oder TIMESTAMP. Der TIMESTAMP-Typ von gehosteten MySQL-Anbietern ist standardmäßig auch 4 Byte, prüfe die Docs.
• ISO 8601 mit Regex parsen. Halb-Implementierungen verwerfen die Zeitzone stillschweigend. Verwende den Plattform-Parser: new Date(s) in JavaScript, datetime.fromisoformat(s) in Python ≥ 3.11, Instant.parse(s) in Java.
• Excel konvertiert Timestamps automatisch. 1747143012345 in Excel einzufügen, ohne es mit ' (einem wörtlichen Apostroph) zu präfixieren, lässt Excel es als Zahl lesen, manchmal in wissenschaftliche Notation konvertierend. Formatiere entweder die Spalte zuerst als Text oder füge mit Apostroph-Präfix ein.

Weitere häufig gestellte Fragen

Warum wurde 1970-01-01 als Epoche gewählt?

Bequemlichkeit. Frühe Unix-Versionen in den 70er Jahren wollten eine Epoche, die innerhalb einer angemessenen Arbeitslebensdauer nicht überlaufen würde. 1970-01-01 war ein rundes Datum nahe der Entwicklungs-Ära, und ein 32-Bit-Sekundenzähler von dort aus erreicht bequem 2038. Die Wahl ist nun in POSIX.1-2017 §4.16 eingraviert und ist eine der stabilsten plattformübergreifenden Vereinbarungen in Software. Es gibt keine inhärente Bedeutung für das Datum, kein historisches Ereignis, keinen astronomischen Anker, nur einen willkürlichen Anker, dem alle zugestimmt haben.

Was ist der Unterschied zwischen UTC, GMT und Zulu-Zeit?

Für Software-Zwecke beziehen sie sich auf die gleiche Wanduhrzeit. UTC (Koordinierte Weltzeit) ist der moderne Standard, definiert durch Atomuhren und das BIPM. GMT (Greenwich Mean Time) ist der ältere britische astronomische Standard, der vor der Atomzeit die de-facto-Weltreferenz war. Zulu-Zeit ist der NATO/militärische Bezeichner für UTC, geschrieben als das Z-Suffix in ISO 8601 (2026-05-13T14:30:00Z). UTC und GMT können bis zu 0,9 Sekunden abweichen, weil UTC gesteuert wird, um nahe an UT1 (mittlerer Sonnenzeit) über Schaltsekunden zu bleiben, aber keine Anwendung, die UT1 nicht direkt verwendet, wird es bemerken.

Warum wird manchmal 1970 angezeigt, wenn ich etwas anderes erwartet hatte?

Zwei häufige Ursachen. Erstens, der Timestamp ist in Millisekunden, wurde aber an eine Funktion übergeben, die Sekunden erwartet, oder umgekehrt, wodurch ein Datum um einen Faktor 1000 versetzt wird. Zweitens, der Wert ist 0 oder NaN, was die meisten Datumsbibliotheken als 1970-01-01T00:00:00Z rendern. Untersuche die rohe Ganzzahlbreite: 10 Ziffern ist Sekunden, 13 ist Millisekunden, 16 ist Mikrosekunden, 19 ist Nanosekunden.

Wird dieses Werkzeug negative Timestamps für Daten vor 1970 behandeln?

Ja. new Date(-86400000) gibt 1969-12-31T00:00:00Z zurück. JavaScripts Date kann jeden Moment von −271821-04-20 bis +275760-09-13 darstellen, was etwa ±100 Millionen Tage von der Epoche entspricht. Außerhalb dieses Bereichs gibt die API Invalid Date zurück. Bei historischen Daten beachte auch den Julianisch-Gregorianischen Übergang (1582 in katholischen Ländern, 1752 in Großbritannien, erst 1923 in Griechenland), bei dem Kalenderdaten um 10 bis 13 Tage sprangen; Datumsbibliotheken variieren darin, wie sie damit umgehen.

Werden meine Timestamp-Daten irgendwohin gesendet?

Nein. Alle Konvertierungen laufen in JavaScript in deinem Browser. Die Seite POSTet niemals irgendeinen Wert, den du eingibst. Öffne den Netzwerk-Tab in DevTools und konvertiere einen Timestamp, du wirst null ausgehende Anfragen während der Konvertierung sehen. Sicher für Tokens mit Timestamp-Claims, interne Log-Zeilen oder alles andere, was du nicht in einen gehosteten Service einfügen würdest.