Unix-Zeit in einem Satz
Unix-Zeit, auch Epoch-Zeit oder POSIX-Zeit genannt, ist eine einzige ganze Zahl, die die Sekunden ab der Epoche 1970-01-01T00:00:00Z zählt. Sie enthält keine Zeitzone, keine Sommerzeit und keinen Kalender, und genau deshalb nutzen Datenbanken, Logdateien, APIs, JWT-Tokens und Dateisysteme sie: Zwei Server auf verschiedenen Kontinenten schreiben für denselben Moment dieselbe Zahl.
Zeitpunkte vor 1970 sind negative Zahlen: -1 ist der 31. Dezember 1969 um 23:59:59 UTC. Der aktuelle Wert liegt knapp unter zwei Milliarden und wächst jeden Tag um 86.400.
Hier ausprobieren: Unix-Timestamp-Umrechner
Vollständige Tool-Seite öffnenSekunden, Millisekunden, Mikrosekunden
Die Definition rechnet in Sekunden, aber viele Systeme speichern feinere Einheiten und nennen das trotzdem Unix-Timestamp. Am schnellsten unterscheidest du sie im Jahr 2026 an der Zahl der Stellen, und genau so erkennt auch der Umrechner auf dieser Seite die Einheit.
Die Einheiten zu verwechseln ist der häufigste Fehler: Behandelst du einen Millisekundenwert als Sekunden, bekommst du ein Datum rund 54.000 Jahre in der Zukunft; behandelst du Sekunden als Millisekunden, landest du im Januar 1970. Zeigt ein umgerechnetes Datum 1970, multipliziere mit 1.000. Zeigt es ein Jahr weit in der Zukunft, teile durch 1.000.
| Einheit | Stellen heute | Beispiel für denselben Moment | Typische Quellen |
|---|---|---|---|
| Sekunden | 10 | 1700000000 | Unix und Linux, PHP time(), MySQL UNIX_TIMESTAMP(), JWT exp und iat |
| Millisekunden | 13 | 1700000000000 | JavaScript Date.now(), Java System.currentTimeMillis(), viele JSON-APIs |
| Mikrosekunden | 16 | 1700000000000000 | PostgreSQL intern, einige Python- und Datenbankwerkzeuge |
| Nanosekunden | 19 | 1700000000000000000 | Go time.UnixNano(), hochauflösendes Tracing |
Zeitzonen und UTC
Ein Timestamp selbst bezieht sich immer auf UTC; Zeitzonen kommen erst ins Spiel, wenn du ihn in ein Kalenderdatum für Menschen umwandelst. Derselbe Wert 1700000000 ist 22:13 Uhr in London, 23:13 Uhr in Berlin und Wien, 17:13 Uhr in New York und 01:13 Uhr am nächsten Tag in Istanbul. An der Zahl ändert sich nichts, nur an der Anzeige.
Deshalb gilt als beste Praxis: Timestamps (oder UTC-Zeiten) speichern und erst im allerletzten Schritt, in der Benutzeroberfläche, in Ortszeit umrechnen. Wer Ortszeiten speichert, bekommt bei der Zeitumstellung doppelte oder fehlende Stunden. Der Umrechner zeigt jeden Timestamp in deiner Ortszeit, in UTC und in einer weiteren Zeitzone, die du unter Zusätzlich anzeigen in wählst, dazu ISO 8601 (2023-11-14T22:13:20.000Z) für APIs und RFC 2822 für E-Mail-Header.
Ein Detail: Unix-Zeit ignoriert Schaltsekunden. Jeder Tag hat genau 86.400 Sekunden, ein Timestamp lässt sich also mit einfacher Rechnung in ein Datum umwandeln. Schaltsekunden wurden von den Uhren aufgefangen, nicht in der Zahl mitgezählt.
Umrechnen in Excel und Google Tabellen
Tabellenkalkulationen zählen Tage seit 1900 statt Sekunden seit 1970, also teilst du durch die Sekunden eines Tages und addierst das Datum der Epoche. Formatiere die Ergebniszelle als Datum oder Datum mit Uhrzeit, sonst siehst du eine Dezimalzahl wie 45244,93. In der deutschen Excel-Version heißt die Funktion DATUM und die Argumente werden mit Semikolon getrennt, in der englischen DATE mit Komma.
Das Ergebnis ist in UTC. Für Ortszeit addierst du die Zeitverschiebung in Stunden geteilt durch 24, zum Beispiel +1/24 für Deutschland, Österreich und die Schweiz im Winter (MEZ) oder +2/24 im Sommer (MESZ), -5/24 für New York im Winter. Excel kennt keine Sommerzeit, eine feste Verschiebung ist in vielen Ländern also das halbe Jahr falsch; große Logs rechnest du besser mit der Listenfunktion des Umrechners um.
| Aufgabe | Formel (Timestamp in A2) |
|---|---|
| Sekunden in Datum (UTC) | =A2/86400+DATUM(1970;1;1) |
| Millisekunden in Datum (UTC) | =A2/86400000+DATUM(1970;1;1) |
| Datum in A2 in Sekunden | =(A2-DATUM(1970;1;1))*86400 |
| Sekunden in MEZ (UTC+1) | =A2/86400+DATUM(1970;1;1)+1/24 |
Umrechnen in JavaScript, Python und SQL
Jede gängige Sprache und Datenbank hat eingebaute Funktionen. Achte auf die Einheit, die jede erwartet: JavaScript arbeitet mit Millisekunden, die meisten anderen mit Sekunden.
| Umgebung | Aktueller Timestamp | Timestamp in Datum |
|---|---|---|
| JavaScript | Math.floor(Date.now() / 1000) | new Date(ts * 1000).toISOString() |
| Python | int(time.time()) | datetime.fromtimestamp(ts, tz=timezone.utc) |
| PHP | time() | gmdate('Y-m-d H:i:s', $ts) |
| MySQL | UNIX_TIMESTAMP() | FROM_UNIXTIME(ts) |
| PostgreSQL | extract(epoch from now()) | to_timestamp(ts) |
| SQL Server | DATEDIFF_BIG(SECOND, '1970-01-01', SYSUTCDATETIME()) | DATEADD(SECOND, ts, '1970-01-01') |
| SQLite | strftime('%s', 'now') | datetime(ts, 'unixepoch') |
Das Jahr-2038-Problem
Viele ältere Systeme speichern Unix-Zeit als vorzeichenbehaftete 32-Bit-Ganzzahl. Ihr größter Wert ist 2.147.483.647, und der wird am 19. Januar 2038 um 03:14:07 UTC erreicht. Eine Sekunde später läuft die Zahl auf einen großen negativen Wert über und das Datum springt zurück in den Dezember 1901. Alles, was Daten in die Zukunft berechnet, etwa Kredite über 20 Jahre, Zertifikate oder geplante Aufgaben, kann schon früher darauf stoßen.
Moderne Betriebssysteme, Sprachen und Datenbanken nutzen 64-Bit-Zeit, die für Milliarden Jahre reicht. Das Risiko steckt in älteren eingebetteten Geräten, Dateiformaten und Datenbankspalten. In MySQL endet zum Beispiel der Spaltentyp TIMESTAMP immer noch im Januar 2038, langlebige Daten sind in DATETIME- oder BIGINT-Spalten also sicherer. Pflegst du alten Code, such nach 32-Bit-Zeitfeldern und int-Spalten, die Timestamps enthalten.
Nützliche Vergleichswerte
- 0 = 1970-01-01 00:00:00 UTC, die Epoche selbst.
- 1000000000 = 2001-09-09 01:46:40 UTC, der erste zehnstellige Timestamp.
- 1700000000 = 2023-11-14 22:13:20 UTC.
- 2000000000 = 2033-05-18 03:33:20 UTC.
- 2147483647 = 2038-01-19 03:14:07 UTC, die 32-Bit-Grenze.
- 86400 = ein Tag, 604800 = eine Woche, 3600 = eine Stunde.