Unix-Zeitstempel- & Epoch-Konverter — Multi-Präzision

Unix-Zeitstempel sofort in Daten umwandeln mit unserem kostenlosen Epoch-Konverter. Erkennt automatisch Sekunden, Millisekunden & Mikrosekunden. Live-Uhr, bidirektional. Ohne Anmeldung, 100 % privat.

Kein Tracking Läuft im Browser Kostenlos

Die gesamte Verarbeitung findet lokal in Ihrem Browser statt. Keine Daten werden an einen Server gesendet.

Aktueller Zeitstempel

Unix-Zeitstempel

Schnellreferenz

Code-Beispiele

Überprüft auf POSIX-Konformität und Präzisionsgenauigkeit — Go Tools Engineering Team · Mar 22, 2026

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 um 00:00:00 UTC vergangen sind, und dient als universelle Zeitreferenz für praktisch alle Computersysteme. Von Linux-Kernels und SQL-Datenbanken bis hin zu JavaScript-Engines und mobilen Betriebssystemen — praktisch jede moderne Plattform speichert und tauscht Zeit als Unix-Zeitstempel aus.

Wie IEEE Std 1003.1 (POSIX) es formal definiert: „Die Unix-Epoche (1. Januar 1970, 00:00:00 UTC) dient als Nullpunkt für die POSIX-Zeit“ — eine Konvention, die so universell übernommen wurde, dass sie heute der De-facto-Standard für maschinenlesbare Zeitstempel weltweit ist. Unix-Zeitstempel werden von der überwältigenden Mehrheit der serverseitigen Systeme, Datenbanken und Netzwerkprotokolle verwendet, einschließlich HTTP-Header, JWT-Tokens und praktisch jeder REST-API.

Die Unix-Epoche selbst — der 1. Januar 1970 — wurde nicht willkürlich gewählt. Unix wurde in den späten 1960er-Jahren bei Bell Labs entwickelt, und 1970 war ein praktischer, runder Startpunkt, der nah genug an der Gegenwart lag, um alle relevanten Daten mit handhabbaren Ganzzahlgrößen darzustellen. Jeder Zeitpunkt kann als vorzeichenbehaftete 64-Bit-Ganzzahl der Sekundenanzahl ab diesem Ankerpunkt ausgedrückt werden. Daten vor der Epoche werden als negative Zahlen dargestellt: Der 31. Dezember 1969 um Mitternacht UTC ist -86400 (ein Tag oder 86.400 Sekunden vor der Epoche).

Moderne Systeme benötigen oft eine feinere Zeitauflösung als ganze Sekunden. Um dies zu ermöglichen, werden Zeitstempel häufig in Millisekunden (Tausendstel einer Sekunde, wie von JavaScripts `Date.now()` oder Javas `System.currentTimeMillis()` zurückgegeben) oder Mikrosekunden (Millionstel einer Sekunde, verwendet in Datenbanken wie PostgreSQL und in Hochfrequenzhandelssystemen) ausgedrückt. Die Präzision lässt sich an der Stellenanzahl erkennen: 10 Stellen bedeuten Sekunden, 13 Stellen bedeuten Millisekunden und 16 Stellen bedeuten Mikrosekunden. Dieser Konverter erkennt die Präzision Ihrer Eingabe automatisch.

Unix-Zeitstempel sind das Rückgrat verteilter Systeme, da sie zeitzonenunabhängig, monoton steigend (unter normalen Bedingungen) und trivial als Ganzzahlen sortierbar sind. Zeiten als Zeitstempel zu speichern und erst bei der Anzeige in menschenlesbare Formate umzuwandeln, ist eine bewährte Praxis, die ganze Kategorien von Zeitzonenfehlern eliminiert. Der Nachteil ist die Lesbarkeit — ein roher Zeitstempel wie 1741965432 ist ohne Konverter nicht aussagekräftig, und genau dafür ist dieses Tool da.

Alle Umrechnungen erfolgen vollständig in Ihrem Browser über die JavaScript Date API — es werden niemals Zeitstempel, Daten oder andere Informationen an einen Server gesendet. Dieses Tool wandelt jeden Unix-Zeitstempel — einschließlich der aktuellen Epoch-Zeit, die in der Live-Uhr oben angezeigt wird — sofort in ein menschenlesbares Datum um, bei vollständiger Privatsphäre.

Zeitstempel sind eng mit anderen Entwicklertools verbunden. UUID v1 und v7 betten Zeitstempel direkt in ihre Bezeichner ein, und API-Antworten mit Zeitstempeln lassen sich oft am besten mit einem JSON-Formatierer zur besseren Lesbarkeit inspizieren. Für einen ausführlichen Leitfaden zu Präzision, Zeitzonenbehandlung und Sommerzeit-Fallstricken mit Codebeispielen in JavaScript, Python und Go lesen Sie unseren Unix-Zeitstempel-Leitfaden.

// Get the current Unix timestamp in JavaScript
const timestampSeconds = Math.floor(Date.now() / 1000);
console.log(timestampSeconds); // → 1741965432

// Milliseconds (native JavaScript)
const timestampMs = Date.now();
console.log(timestampMs); // → 1741965432000

// Convert timestamp back to a Date object
const date = new Date(timestampSeconds * 1000);
console.log(date.toISOString()); // → '2025-03-14T15:37:12.000Z'

// Python equivalent
// import time
// timestamp = int(time.time())  # → 1741965432

Hauptfunktionen

Automatische Präzisionserkennung

Erkennt automatisch, ob Ihr Zeitstempel in Sekunden (10 Stellen), Millisekunden (13 Stellen) oder Mikrosekunden (16 Stellen) vorliegt — kein manuelles Umschalten erforderlich.

Bidirektionale Umrechnung

Wandeln Sie Zeitstempel in menschenlesbare Daten um, oder wählen Sie ein beliebiges Datum und eine Uhrzeit, um sofort den entsprechenden Unix-Zeitstempel in allen drei Präzisionsformaten zu erhalten.

Live-Epoch-Uhr

Sehen Sie den aktuellen Unix-Zeitstempel in Echtzeit ticken, sodass Sie immer einen genauen Referenzpunkt für Ihre Umrechnungen und Berechnungen haben.

Multi-Format-Ausgabe

Jede Umrechnung gibt gleichzeitig UTC-Zeit, Ihre lokale Zeitzone, ISO-8601-Format und eine benutzerfreundliche relative Zeit (z. B. „vor 3 Tagen“) aus.

100 % browserseitige Verarbeitung

Alle Umrechnungen erfolgen vollständig in Ihrem Browser über die JavaScript Date API. Es werden keine Zeitstempel, Daten oder persönlichen Informationen an einen Server übertragen.

Zeitformat-Vergleich

ISO 8601

2025-03-14T15:37:12Z

Sowohl menschenlesbar als auch lexikografisch sortierbar. Der Standard für Datenaustausch und APIs. Gegenüber Unix-Zeitstempeln bevorzugt, wenn menschliche Lesbarkeit wichtig ist.

RFC 2822

Fri, 14 Mar 2025 15:37:12 +0000

Menschenlesbar, aber nicht sortierbar. Wird hauptsächlich in E-Mail-Headern (Datumsfeld) verwendet. Weniger kompakt als ISO 8601 und Unix-Zeitstempel.

Menschliches Datum

14. März 2025, 15:37

Das am besten lesbare Format für Endbenutzer, aber nicht sortierbar oder für programmatische Verwendung geeignet. Am besten für die UI-Anzeigeebene reserviert.

Beispiele

Standard-Unix-Zeitstempel (Sekunden)

1741965432

2025-03-14T15:37:12Z

Ein 10-stelliger Zeitstempel in Sekunden — das gängigste Format, verwendet von Unix/Linux-Systemen, Unix-APIs, JWT-Tokens und Server-Logs. Dieser Wert entspricht dem Pi-Tag 2025 um 15:37:12 UTC.

Y2K-Zeitstempel — 1. Januar 2000

946684800

2000-01-01T00:00:00Z

Der Unix-Zeitstempel für den Y2K-Moment: exakt 946.684.800 Sekunden nach der Unix-Epoche. Dies ist ein nützlicher Kalibrierwert — wenn Ihr Konverter für diese Eingabe den 1. Januar 2000 ausgibt, funktioniert er korrekt.

Negativer Zeitstempel (vor der Epoche)

-86400

1969-12-31T00:00:00Z

Negative Unix-Zeitstempel stellen Daten vor dem 1. Januar 1970 dar. Der Wert -86400 liegt exakt einen Tag (86.400 Sekunden) vor der Epoche, was dem 31. Dezember 1969 um Mitternacht UTC entspricht. Nicht alle Systeme unterstützen negative Zeitstempel, aber dieser Konverter behandelt sie korrekt.

Millisekunden-Zeitstempel (13 Stellen)

1741965432000

2025-03-14T15:37:12.000Z

Ein 13-stelliger Zeitstempel in Millisekunden — das native Format von JavaScripts Date.now(), Javas System.currentTimeMillis() und den meisten modernen REST-APIs. Dies entspricht dem ersten Beispiel multipliziert mit 1000. Die automatische Erkennung erkennt die 13-stellige Länge und interpretiert sie korrekt als Millisekunden.

Anleitung

1

Umrechnungsrichtung wählen

Wählen Sie „Zeitstempel → Datum“, um einen Unix-Zeitstempel in ein menschenlesbares Datum zu dekodieren, oder „Datum → Zeitstempel“, um ein Kalenderdatum und eine Uhrzeit in einen Unix-Zeitstempel umzuwandeln.
2

Wert eingeben

Fügen Sie einen Unix-Zeitstempel ein oder geben Sie ihn ein (z. B. 1741965432 oder 1741965432000). Das Tool erkennt automatisch, ob es sich um Sekunden, Millisekunden oder Mikrosekunden handelt. Für Datum → Zeitstempel wählen Sie Jahr, Monat, Tag, Stunde, Minute und Sekunde über die Datumsauswahl.
3

Umgerechnetes Ergebnis kopieren

Sehen Sie das Ergebnis sofort in UTC, Ortszeit, ISO 8601 und relativer Zeit. Klicken Sie auf die Kopieren-Schaltfläche neben einem beliebigen Format, um es direkt in Ihre Zwischenablage zu kopieren.

Häufige Anwendungsfälle

API-Entwicklung und Debugging: Dekodieren Sie undurchsichtige Zeitstempel in API-Antworten, JWT-Token-Payloads (iat-, exp-, nbf-Claims), Webhook-Ereignisdaten und Logeinträgen. Überprüfen Sie sofort, ob ein Authentifizierungstoken abgelaufen ist oder wann ein Ereignis stattfand.
Datenbank-Zeitstempelspeicherung und -abfragen: Konvertieren Sie zwischen Unix-Zeitstempeln und menschenlesbaren Daten beim Schreiben von Datenbankabfragen, Inspizieren gespeicherter Datensätze oder Überprüfen, ob Datumsbereichsfilter in Ihren WHERE-Klauseln korrekt angegeben sind.
Logdatei-Analyse und -Korrelation: Viele System- und Anwendungslogs zeichnen Ereignisse als Unix-Zeitstempel auf. Konvertieren Sie verdächtige Logeinträge in menschenlesbare Zeiten, um Ereignisse über mehrere Dienste hinweg zu korrelieren, Angriffszeitfenster zu identifizieren oder den genauen Moment eines Fehlers zu bestimmen.
JWT-Token-Ablaufüberprüfung: JSON Web Tokens kodieren iat (ausgestellt am), exp (läuft ab am) und nbf (nicht vor) als Unix-Zeitstempel in ihrem Payload. Fügen Sie diese Werte direkt ein, um Gültigkeitszeitfenster des Tokens zu überprüfen, ohne manuell die Epoch-Berechnung durchzuführen.
Cron-Job-Planung: Überprüfen Sie, ob Cron-Job-Zeitpläne, geplante Aufgaben und zeitbasierte Auslöser mit den beabsichtigten Ausführungszeitfenstern übereinstimmen, indem Sie vorgeschlagene Laufzeiten in Zeitstempel und zurück konvertieren.
Zeitzonen-übergreifende Datumskoordination: Unix-Zeitstempel sind von Natur aus zeitzonenneutral. Verwenden Sie diesen Konverter, um einen gemeinsamen Referenzpunkt bei der Koordination von Daten und Fristen über Teams in verschiedenen Zeitzonen hinweg festzulegen und das UTC-Äquivalent jeder Ortszeit zu bestätigen.

Technische Details

Definition des Unix-Zeitstempels: Ein Unix-Zeitstempel ist die ganzzahlige Anzahl der Sekunden, die seit der Unix-Epoche vergangen sind: 1. Januar 1970, 00:00:00 UTC (Koordinierte Weltzeit). Der Wert ist unabhängig von der lokalen Zeitzone des Betrachters identisch, was ihn zu einer idealen zeitzonenneutralen Darstellung zum Speichern und Vergleichen von Zeiten macht.
Maximaler Wert einer vorzeichenbehafteten 32-Bit-Ganzzahl: Der Maximalwert einer vorzeichenbehafteten 32-Bit-Ganzzahl beträgt 2.147.483.647. Als Unix-Zeitstempel entspricht dies dem 19. Januar 2038 um 03:14:07 UTC. Systeme, die Zeitstempel in vorzeichenbehafteten 32-Bit-Ganzzahlen speichern, werden zu diesem Zeitpunkt überlaufen — ein Problem, das als Jahr-2038-Problem bekannt ist. 64-Bit-Systeme können Daten Milliarden von Jahren in der Zukunft darstellen.
JavaScript verwendet Millisekunden: JavaScripts Date.now() und new Date().getTime() geben die Anzahl der Millisekunden seit der Epoche zurück — nicht Sekunden. Dies erzeugt 13-stellige Zahlen. Um in den Standard-Unix-Zeitstempel in Sekunden umzurechnen, teilen Sie durch 1000 und runden ab: Math.floor(Date.now() / 1000). Viele APIs und Tools erwarten Sekunden, daher ist dieser Umrechnungsschritt entscheidend.
Negative Zeitstempel stellen Daten vor der Epoche dar: Unix-Zeitstempel können negativ sein, um Daten vor dem 1. Januar 1970 darzustellen. Beispielsweise repräsentiert -86400 den 31. Dezember 1969 um 00:00:00 UTC. Der Bereich eines vorzeichenbehafteten 64-Bit-Zeitstempels erstreckt sich von ungefähr 292 Milliarden Jahren vor der Epoche bis 292 Milliarden Jahre danach — mehr als ausreichend für jede praktische Anwendung.
Unix-Zeit berücksichtigt keine Schaltsekunden: Die Unix-Zeit geht von exakt 86.400 Sekunden pro Tag aus (24 Stunden × 60 Minuten × 60 Sekunden). In der Realität werden gelegentlich Schaltsekunden vom IERS eingefügt, um UTC mit der Erdrotation synchron zu halten. Dies bedeutet, dass die Unix-Zeit in Bezug auf TAI (Internationale Atomzeit) nicht perfekt linear ist, und die Differenz wächst im Laufe der Zeit. Für die meisten Anwendungen ist diese Diskrepanz irrelevant, aber Präzisionszeitmessungssysteme müssen sie berücksichtigen.

Best Practices

Zeitstempel immer in UTC speichern: Speichern Sie Zeitstempel in UTC (oder als Unix-Zeitstempel) und konvertieren Sie sie erst auf der Anzeigeebene in die Ortszeit. Das Mischen von Zeitzonen in Ihrer Datenbank ist eine häufige Fehlerquelle, die schwer zu reproduzieren und zu debuggen ist, besonders rund um Sommerzeitumstellungen.
Millisekunden-Präzision für moderne APIs verwenden: Die meisten modernen APIs, JavaScript-Umgebungen und Datenbanken verwenden Millisekunden (13-stellige Zeitstempel) statt Sekunden (10-stellige Zeitstempel). Bestätigen Sie bei der Integration mit externen Systemen die erwartete Präzision — die Übergabe eines Millisekunden-Zeitstempels dort, wo Sekunden erwartet werden, erzeugt Daten ungefähr 11.000 Jahre in der Zukunft.
Vorsicht vor dem Jahr-2038-Problem: Systeme, die Unix-Zeitstempel in vorzeichenbehafteten 32-Bit-Ganzzahlen speichern, werden am 19. Januar 2038 um 03:14:07 UTC überlaufen. Prüfen Sie Legacy-Systeme auf 32-Bit-Zeitstempelfelder und migrieren Sie zu 64-Bit-Ganzzahlen oder ISO-8601-Zeichenketten. Die meisten modernen Sprachen und Datenbanken verwenden standardmäßig 64-Bit-Zeitstempel, aber eingebettete Systeme, ältere Datenbanken und Dateisysteme können weiterhin betroffen sein.
Nie auf clientseitige Uhren für Sicherheit vertrauen: Client-Geräteuhren können auf beliebige Werte gestellt werden, versehentlich oder böswillig. Verwenden Sie niemals einen vom Client gelieferten Zeitstempel für sicherheitskritische Logik wie JWT-Ablaufprüfungen, Sitzungs-Timeouts oder Rate Limiting. Validieren Sie Zeitstempel immer auf dem Server mithilfe einer vertrauenswürdigen Zeitquelle.
ISO 8601 für menschenlesbaren Austausch verwenden: Wenn Sie ein Zeitstempelformat benötigen, das sowohl maschinenlesbar als auch menschenlesbar ist — z. B. in Logdateien, Konfigurationsdateien oder API-Antworten, die ein Entwickler lesen könnte — ist ISO 8601 (z. B. 2025-03-14T15:37:12Z) die beste Wahl. Es ist lexikografisch sortierbar, eindeutig und wird von praktisch allen modernen Parsern unterstützt.

Häufig gestellte Fragen

Warum beginnt die Unix-Zeit am 1. Januar 1970?

Das Unix-Epochendatum des 1. Januar 1970 wurde von den Entwicklern von Unix bei Bell Labs in den späten 1960er-Jahren als bequemer, runder Startpunkt gewählt, der sowohl zeitnah als auch rechnerisch praktikabel war. Damals wurden Zeitstempel in 32-Bit-Ganzzahlen gespeichert, sodass die Epoche nah genug an der Gegenwart liegen musste, damit gängige Daten in einer Zahl handhabbarer Größe Platz fanden. 1970 war einfach ein sauberes, rundes Jahr nach dem Beginn der Systementwicklung. Der 1. Januar 1970 hat keine tiefgreifende technische Bedeutung — es war eine ingenieurstechnische Pragmatik. Andere Systeme wählten unterschiedliche Epochen: Die klassische Macintosh-Toolbox verwendete den 1. Januar 1904; Windows NT nutzt den 1. Januar 1601; die GPS-Zeit beginnt am 6. Januar 1980. Jede Wahl spiegelt die Ära und die Designbeschränkungen des jeweiligen Systems wider. Was die Unix-Epoche verankert hat, ist die Tatsache, dass Unix zum dominierenden Betriebssystem in der Informatik wurde, und jede große Programmiersprache, Datenbank und jedes Betriebssystem schließlich die Unix-Zeit als universellen Standard für maschinenlesbare Zeitstempel übernahm. Heute ist die Unix-Epoche praktisch eine universelle Konstante in der Informatik, anerkannt von jeder großen Plattform — von Linux-Kernels über JavaScript-Engines bis hin zu SQL-Datenbanken. Die Wahl hat eine bekannte Konsequenz: Daten vor dem 1. Januar 1970 werden als negative Zahlen dargestellt, die einige ältere Systeme nicht verarbeiten können. Für historische Daten und astronomische Berechnungen werden manchmal alternative Zeitstempelformate bevorzugt. Für die überwiegende Mehrheit der Softwareentwicklung deckt die Unix-Epoche jedoch alle relevanten Daten problemlos ab.

Was ist das Jahr-2038-Problem?

Das Jahr-2038-Problem (auch Y2K38 oder Epochalypse genannt) ist ein Informatikproblem, das Systeme betrifft, die Unix-Zeitstempel als vorzeichenbehaftete 32-Bit-Ganzzahlen speichern. Eine vorzeichenbehaftete 32-Bit-Ganzzahl kann Werte von -2.147.483.648 bis 2.147.483.647 aufnehmen. Als Unix-Zeitstempel interpretiert entspricht der Maximalwert von 2.147.483.647 dem 19. Januar 2038 um 03:14:07 UTC. Eine Sekunde später wird der Zähler überlaufen und auf den negativsten darstellbaren Wert umschwenken, der dem 13. Dezember 1901 entspricht — wodurch diese Systeme zukünftige Daten als weit in der Vergangenheit liegend interpretieren. Die Konsequenzen können von trivial bis katastrophal reichen, je nachdem, wie Zeitstempel verwendet werden. Systeme könnten gültige Zukunftsdaten bei der Eingabevalidierung ablehnen, zeitkritische Datensätze falsch sortieren, Ablaufdaten für Zertifikate und Tokens falsch berechnen oder beim Auftreten des Überlaufwerts komplett abstürzen. Die Lösung ist unkompliziert: Migration zu vorzeichenbehafteten 64-Bit-Ganzzahlen für die Zeitstempelspeicherung. Ein 64-Bit-Zeitstempel kann Daten ungefähr 292 Milliarden Jahre vor und nach der Epoche darstellen — weit jenseits jeder praktischen Anforderung. Die meisten modernen Betriebssysteme, Programmiersprachen und Datenbanken verwenden intern bereits 64-Bit-Zeitstempel. Das Risiko liegt in Legacy-Code, eingebetteten Systemen, 32-Bit-Betriebssystemen, die noch in Produktion sind, Dateisystem-Metadaten (wie den Zeitstempelfeldern von FAT32) und Datenbankspalten, die als INT statt BIGINT definiert sind. Entwickler sollten ihre Systeme jetzt prüfen. Die Migration von 32-Bit- auf 64-Bit-Zeitstempel muss vor 2038 erfolgen, und in der Praxis können Systeme mit langlebigen Datensätzen (Hypotheken, Infrastrukturanlagen, Rechtsdokumente) das Problem viel früher antreffen, wenn Zukunftsdaten in betroffene Felder eingegeben werden.

Was ist der Unterschied zwischen Sekunden-, Millisekunden- und Mikrosekunden-Zeitstempeln?

Unix-Zeitstempel gibt es in drei gängigen Präzisionen, die sich durch die Stellenanzahl des Werts unterscheiden: **Sekunden (10 Stellen)**: Das ursprüngliche und häufigste Unix-Zeitstempelformat. `1741965432` repräsentiert eine bestimmte Sekunde. Verwendet von: Unix/Linux-Systemaufrufen (`time()`), den meisten Unix-Dienstprogrammen, JWT-Tokens (`iat`, `exp` Claims), HTTP-Headern (`Last-Modified`) und vielen REST-APIs. Der aktuelle Zeitstempel ist ungefähr 10 Stellen lang. **Millisekunden (13 Stellen)**: Präzision von einer Tausendstelsekunde. `1741965432000` ist derselbe Moment wie oben, multipliziert mit 1.000. Verwendet von: JavaScripts `Date.now()`, Javas `System.currentTimeMillis()`, Node.js, den meisten modernen JavaScript/TypeScript-APIs, Redis und vielen Datenbank-Clients. Wenn Sie einen 13-stelligen Zeitstempel in einer JSON-API-Antwort sehen, sind es fast sicher Millisekunden. **Mikrosekunden (16 Stellen)**: Präzision von einer Millionstelsekunde. `1741965432000000` ist derselbe Moment multipliziert mit 1.000.000. Verwendet von: PostgreSQLs `TIMESTAMP`- und `TIMESTAMPTZ`-Typen, Pythons `time.time_ns()` (obwohl dies Nanosekunden zurückgibt), Hochfrequenzhandelssystemen und Netzwerkpaketanalyse-Tools. Der häufigste Fehler ist das Mischen von Präzisionen — z. B. die Übergabe eines Millisekunden-Zeitstempels an eine Funktion, die Sekunden erwartet. Dies erzeugt Daten ungefähr 11.574 Jahre in der Zukunft. Prüfen Sie immer die Dokumentation der API oder des Systems, mit dem Sie arbeiten, um die erwartete Präzision zu bestätigen, und nutzen Sie die automatische Erkennung dieses Konverters als Plausibilitätsprüfung.

Berücksichtigt die Unix-Zeit Schaltsekunden?

Nein — die Unix-Zeit berücksichtigt keine Schaltsekunden, und dies ist eine ihrer bekannten Einschränkungen für Anwendungen zur Präzisionszeitmessung. Schaltsekunden werden gelegentlich vom Internationalen Dienst für Erdrotation und Referenzsysteme (IERS) eingefügt (oder theoretisch entfernt, obwohl bisher noch keine entfernt wurde), um UTC mit der leicht unregelmäßigen Erdrotation synchron zu halten. Stand 2026 wurden seit ihrer Einführung 1972 insgesamt 27 Schaltsekunden eingefügt. Die Unix-Zeit geht von einem perfekt regelmäßigen Kalender mit exakt 86.400 Sekunden pro Tag (24 × 60 × 60) aus. Wenn eine Schaltsekunde eingefügt wird, hat die reale Welt eine Sekunde, die die Unix-Zeit ignoriert. Verschiedene Betriebssysteme handhaben dies unterschiedlich: Linux „verschmiert“ die Schaltsekunde traditionell, indem die Uhr für einen Zeitraum um den Einfügepunkt herum leicht verlangsamt wird (Googles Ansatz, auch „Leap Smearing“ genannt); einige Systeme duplizieren die Sekunde bei 23:59:60 UTC; andere überspringen die Anpassung einfach und lassen die Uhr driften. Für die überwältigende Mehrheit der Softwareanwendungen — Webdienste, APIs, Datenbanken, Geschäftslogik — sind die ~27 Sekunden akkumulierte Schaltsekunden-Diskrepanz über 50+ Jahre völlig irrelevant. Der Unterschied ist für jede benutzerseitige Anwendung nicht wahrnehmbar. Wo Schaltsekunden wichtig sind: GPS-Synchronisation, astronomische Beobachtung, Paketnetzwerk-Timing-Protokolle (PTP/IEEE 1588) und jedes System, das Unix-Zeitstempel präzise mit TAI (Internationale Atomzeit) korrelieren muss. Wenn Ihre Anwendung in diese Kategorien fällt, sollten Sie eine Zeitmessungsbibliothek verwenden, die Schaltsekunden explizit unterstützt, oder direkt mit TAI-Zeitstempeln arbeiten.

Können Unix-Zeitstempel negativ sein?

Ja, Unix-Zeitstempel können negativ sein, und negative Zeitstempel sind eine legitime und wohldefinierte Methode, um Daten vor der Unix-Epoche (1. Januar 1970, 00:00:00 UTC) darzustellen. Jede Sekunde vor der Epoche entspricht einer Verringerung um 1 von Null. Zum Beispiel repräsentiert -1 den 31. Dezember 1969 um 23:59:59 UTC; -86400 repräsentiert den 31. Dezember 1969 um 00:00:00 UTC (genau einen Tag vor der Epoche); und -2208988800 repräsentiert den 1. Januar 1900 um 00:00:00 UTC. Die meisten modernen Programmiersprachen und Betriebssysteme unterstützen negative Zeitstempel. Pythons `datetime.fromtimestamp(-86400)` gibt korrekt den 31. Dezember 1969 zurück. JavaScripts `new Date(-86400 * 1000)` rendert korrekt dasselbe Datum. PostgreSQL speichert Zeitstempel als 8-Byte-Ganzzahlen und behandelt Daten Tausende von Jahren vor der Epoche korrekt. Allerdings gibt es wichtige Einschränkungen. Einige ältere Systeme, Bibliotheken oder Datenbanktreiber unterstützen negative Zeitstempel möglicherweise nicht korrekt. 32-Bit-Systeme, die vorzeichenlose Ganzzahlen für Zeitstempel verwenden, können negative Werte überhaupt nicht darstellen. Einige Datenbanken, die als UNSIGNED BIGINT oder DATETIME-Typen definiert sind, können negative Werte ablehnen oder als weit in der Zukunft liegende Daten interpretieren. Für historische Daten (alles vor 1970) ist es oft sicherer, das Datum als ISO-8601-Zeichenkette zu speichern oder einen datenbanknativen Datumstyp zu verwenden, anstatt sich für die Portabilität auf negative Unix-Zeitstempel zu verlassen. Dieser Konverter behandelt negative Zeitstempel korrekt und zeigt das entsprechende Datum vor 1970 an.

Wie erhalte ich den aktuellen Unix-Zeitstempel in JavaScript, Python oder anderen Sprachen?

Den aktuellen Unix-Zeitstempel zu erhalten ist in jeder gängigen Programmiersprache unkompliziert: **JavaScript / TypeScript:** ```javascript // Seconds (most APIs expect this) const seconds = Math.floor(Date.now() / 1000); // Milliseconds (JavaScript native) const milliseconds = Date.now(); ``` **Python:** ```python import time seconds = int(time.time()) # 1741965432 import datetime milliseconds = int(datetime.datetime.now(datetime.UTC).timestamp() * 1000) ``` **Go:** ```go import "time" seconds := time.Now().Unix() // int64 milliseconds := time.Now().UnixMilli() // int64 microseconds := time.Now().UnixMicro() // int64 ``` **Java:** ```java long seconds = System.currentTimeMillis() / 1000L; long milliseconds = System.currentTimeMillis(); // Or with java.time (Java 8+): long seconds2 = Instant.now().getEpochSecond(); ``` **PHP:** ```php $seconds = time(); // integer $milliseconds = round(microtime(true) * 1000); ``` **Ruby:** ```ruby seconds = Time.now.to_i milliseconds = (Time.now.to_f * 1000).to_i ``` **Bash / Shell:** ```bash date +%s # seconds date +%s%3N # milliseconds (GNU date) ``` Das Wichtigste ist, dass JavaScript nativ in Millisekunden arbeitet, während praktisch jede andere Sprache standardmäßig Sekunden verwendet. Seien Sie immer explizit, welche Präzision Sie verwenden, und dokumentieren Sie dies in Ihren API-Verträgen, um Integrationsfehler zu vermeiden.

Wie wandle ich Epoch-Zeit in ein menschenlesbares Datum um?

Es gibt drei schnelle Wege, Epoch-Zeit (Unix-Zeitstempel) in ein menschenlesbares Datum umzuwandeln: **1. Diesen Online-Konverter verwenden (am schnellsten)** Fügen Sie Ihren Epoch-Zeitstempel in das Eingabefeld oben ein. Das Tool erkennt automatisch, ob er in Sekunden, Millisekunden oder Mikrosekunden vorliegt, und zeigt das Ergebnis sofort in UTC, Ihrer lokalen Zeitzone, ISO 8601 und relativem Zeitformat an. Klicken Sie auf „Kopieren“, um ein beliebiges Format zu übernehmen. **2. Code verwenden** In JavaScript: `new Date(1741965432 * 1000).toISOString()` gibt `'2025-03-14T15:37:12.000Z'` zurück. In Python: `from datetime import datetime, UTC; datetime.fromtimestamp(1741965432, UTC)` liefert dasselbe Ergebnis. Beachten Sie, dass JavaScript Millisekunden erwartet, während Python Sekunden erwartet — die häufigste Ursache von Umrechnungsfehlern. **3. Die Kommandozeile verwenden** Unter Linux oder macOS mit GNU date: `date -d @1741965432` (Linux) oder `date -r 1741965432` (macOS). In Windows PowerShell: `[DateTimeOffset]::FromUnixTimeSeconds(1741965432).DateTime`. Alle drei Methoden liefern dasselbe Ergebnis. Der Online-Konverter oben ist die schnellste Option, wenn Sie eine schnelle Antwort benötigen, ohne ein Terminal zu öffnen oder Code zu schreiben.

Wie lautet der aktuelle Unix-Zeitstempel jetzt?

Der aktuelle Unix-Zeitstempel wird in der Live-Uhr oben auf dieser Seite angezeigt und jede Sekunde aktualisiert. Der Unix-Zeitstempel ist einfach die Anzahl der Sekunden seit dem 1. Januar 1970, 00:00:00 UTC, und erhöht sich jede Sekunde um exakt 1. Um den aktuellen Zeitstempel programmatisch zu erhalten: - **JavaScript**: `Math.floor(Date.now() / 1000)` (Sekunden) oder `Date.now()` (Millisekunden) - **Python**: `import time; int(time.time())` - **Bash**: `date +%s` Stand 2026 liegt der aktuelle Unix-Zeitstempel im Bereich von 1,77 Milliarden (10 Stellen). Er wird um Mai 2033 die 2 Milliarden erreichen, und der Maximalwert für 32-Bit-Systeme (2.147.483.647) wird am 19. Januar 2038 um 03:14:07 UTC erreicht — das sogenannte Jahr-2038-Problem. Setzen Sie ein Lesezeichen für diese Seite, damit Sie die aktuelle Epoch-Zeit immer mit einem Klick zur Hand haben.

Ich muss einen Zeitstempel in meiner API-Antwort debuggen — wie wandle ich ihn um?

Kopieren Sie den Zeitstempelwert aus Ihrer API-Antwort (es wird typischerweise eine 10- oder 13-stellige Zahl in einem JSON-Feld wie „created_at“ oder „timestamp“ sein). Fügen Sie ihn direkt in das Eingabefeld oben ein — das Tool erkennt automatisch, ob er in Sekunden oder Millisekunden vorliegt, und zeigt sofort das UTC-Datum, Ihre Ortszeit und das ISO-8601-Format an. Wenn der Zeitstempel in einem JWT-Token verschachtelt ist, dekodieren Sie zuerst den JWT-Payload (der Base64URL-kodiert ist), um die Felder iat, exp oder nbf zu extrahieren, und fügen Sie diese Werte dann hier ein. Für das Stapel-Debugging verwenden Sie das Code-Snippet: new Date(timestamp * 1000).toISOString() in Ihrer Browser-Konsole, um mehrere Zeitstempel schnell zu prüfen, ohne Ihre Entwicklertools zu verlassen.

Wie erhalte ich den aktuellen Unix-Zeitstempel in Python/JavaScript/Go?

In JavaScript verwenden Sie Math.floor(Date.now() / 1000) für Sekunden oder Date.now() für Millisekunden. In Python verwenden Sie import time; int(time.time()) für Sekunden oder int(time.time() * 1000) für Millisekunden. In Go verwenden Sie time.Now().Unix() für Sekunden, time.Now().UnixMilli() für Millisekunden oder time.Now().UnixMicro() für Mikrosekunden. Beachten Sie, dass JavaScript nativ in Millisekunden arbeitet, während Python und Go standardmäßig Sekunden verwenden — dies ist die häufigste Einzelursache für Zeitstempelfehler bei der Integration von Systemen, die in verschiedenen Sprachen geschrieben sind. Dokumentieren Sie immer, welche Präzision Ihre API erwartet, in Ihrer OpenAPI/Swagger-Spezifikation.

Was passiert mit Unix-Zeitstempeln während der Sommerzeitumstellung?

Unix-Zeitstempel werden von Sommerzeitumstellungen (DST) überhaupt nicht beeinflusst, da sie auf UTC basieren, das keine Sommerzeit kennt. Wenn Uhren in einer lokalen Zeitzone „vorgestellt“ oder „zurückgestellt“ werden, erhöht sich der Unix-Zeitstempel weiterhin exakt um 1 pro Sekunde, ohne Lücke oder Wiederholung. Dies ist einer der Hauptvorteile der Speicherung von Zeiten als Unix-Zeitstempel anstelle lokaler Datums-Zeichenketten. Wenn Sie jedoch einen Unix-Zeitstempel während einer Sommerzeitumstellung in Ortszeit umwandeln, kann dieselbe Ortszeit zwei verschiedenen Unix-Zeitstempeln entsprechen (während der „Zurückstellen“-Stunde, wenn die Uhren sich wiederholen). Speichern und vergleichen Sie Zeitstempel immer in UTC und konvertieren Sie erst für Anzeigezwecke in die Ortszeit.

Ich habe einen Zeitstempel in Millisekunden — wie wandle ich ihn in Sekunden um?

Teilen Sie den Millisekunden-Zeitstempel durch 1000 und verwerfen Sie den Dezimalteil. In JavaScript: Math.floor(ms / 1000). In Python: ms // 1000 (Ganzzahldivision). Zum Beispiel wird 1741965432000 (Millisekunden) zu 1741965432 (Sekunden). Sie können Millisekunden-Zeitstempel an ihrer 13-stelligen Länge im Vergleich zur 10-stelligen Länge von Sekunden-Zeitstempeln erkennen. Dieses Tool erkennt die Präzision automatisch, sodass Sie beide Formate direkt einfügen können. Die umgekehrte Umrechnung (Sekunden zu Millisekunden) ist einfach eine Multiplikation mit 1000: 1741965432 * 1000 = 1741965432000. Achten Sie darauf, nicht versehentlich einen Millisekundenwert an eine Funktion zu übergeben, die Sekunden erwartet — das Ergebnis wäre ein Datum ungefähr 11.574 Jahre in der Zukunft.