Artikel

Unix-Timestamps und Cron-Ausdrücke erklärt

Ein Unix-Timestamp ist nur eine Ganzzahl. Ein Cron-Ausdruck sind nur fünf Felder. Beide tauchen ständig in der Backend-Arbeit auf und beide bringen Menschen auf vorhersehbare Weise ins Straucheln: der eine wegen Zeitzonen, der andere wegen der Einheit.

Verfasst von Bastien Sulyan · Veröffentlicht am 28. Juni 2026

Was ein Unix-Timestamp ist

Ein Unix-Timestamp zählt die Anzahl der Sekunden, die seit 1970-01-01 00:00:00 UTC vergangen sind, einem Referenzpunkt, der als Unix-Epoch bekannt ist. Diese Definition hat zwei wichtige Konsequenzen. Erstens ist die Zählung in UTC: Es gibt keine Zeitzone, die in der Zahl selbst eingebettet ist. 1718400000 bedeutet denselben Moment überall auf der Erde, unabhängig davon, wo sich die Maschine befindet, die ihn speichert. Zweitens ist die Epoch in Sekunden definiert, nicht in einer anderen Einheit. Ein Wert wie 1718400000 ist immer Sekunden seit Mitternacht 1. Januar 1970 UTC, es sei denn, ein System oder Protokoll hat eine andere Wahl explizit getroffen. Timestamps sind per Design zeitzonenfrei, was genau der Grund ist, warum sie für Protokollierung, Datenbanken und systemübergreifende Kommunikation nützlich sind, bei der Uhren in verschiedenen Regionen auf denselben Moment eindeutig verweisen müssen.

Zeitstrahl mit der Unix-Epoch bei 1970-01-01 00:00:00 UTC auf der linken Seite, einem aktuellen Timestamp in der Mitte und der 2038-Überlauf-Grenze auf der rechten Seite, markiert mit dem Maximum einer vorzeichenbehafteten 32-Bit-Ganzzahl.

Sekunden, Millisekunden und das Jahr-2038-Problem

Viele moderne Laufzeitumgebungen und APIs verwenden Millisekunden statt Sekunden. JavaScript's Date.now() gibt Millisekunden zurück, also ist 1718400000000 derselbe Moment wie der sekundengenauer Wert 1718400000. Wenn man einen unbekannten Timestamp erhält, sagt die Größenordnung die Einheit: Eine 10-stellige Zahl ist fast immer Sekunden; eine 13-stellige Zahl ist fast immer Millisekunden. Das Jahr-2038-Problem entsteht aus einer anderen Wahl: einen sekundengenauen Timestamp in einer vorzeichenbehafteten 32-Bit-Ganzzahl zu speichern. Der Maximalwert einer vorzeichenbehafteten 32-Bit-Ganzzahl ist 2147483647, was 2038-01-19 03:14:07 UTC entspricht. Nach dieser Sekunde läuft der Zähler auf eine große negative Zahl über und das Datum springt auf 1901 auf Systemen zurück, die die Grenze nicht behandeln. Die Lösung ist die Verwendung von 64-Bit-Speicher. Die meisten aktuellen Betriebssysteme und Datenbanken tun dies bereits, aber eingebettete Systeme, Netzwerkgeräte und alte Dateiformate, deren Feldbreite vor Jahrzehnten festgelegt wurde, bleiben gefährdet.

Epoch in ein lesbares Datum umrechnen: der Zeitzonenschritt

Die Umrechnung eines Epoch-Wertes in ein lesbares Datum erfordert zwei Schritte: die UTC-Datumskomponenten aus der Ganzzahl abrufen, dann einen UTC-Offset anwenden, um die Ortszeit zu erhalten. Der Timestamp selbst ist UTC. Wenn man fragt, welches Datum 1718325000 darstellt, lautet die korrekte Antwort 2024-06-14 um 00:30 Uhr UTC. In New York (UTC-4 im Sommer) fällt dieselbe Sekunde auf den Vorabend, 2024-06-13 um 20:30 Uhr: Das Datum ändert sich, nicht nur die Uhrzeit. Dies ist der Schritt, der zu falschen Ergebnissen führt, wenn er übersprungen wird: Ein Entwickler protokolliert den rohen Timestamp in UTC, ein Reporting-Tool rendert ihn in Ortszeit ohne Konvertierung, und das Datum erscheint um Stunden oder einen ganzen Tag versetzt. Das Timestamp-Konverter-Tool auf Sunasty behandelt dies explizit: Man gibt einen Epoch-Wert ein, und das Tool zeigt das UTC-Datum und die UTC-Zeit direkt neben dem lokalen Datum und der lokalen Zeit des eigenen Geräts, sodass ein solcher Tageswechsel auf einen Blick sichtbar ist. Die Konvertierung läuft vollständig im Browser und nichts, was man einfügt, wird irgendwohin gesendet.

Zwei Kalenderraster nebeneinander für denselben Epoch-Wert: Das UTC-Raster hebt einen Kalendertag hervor, das Raster für New York (UTC-4) hebt den vorherigen Tag hervor, was zeigt, wie das lokale Datum durch die Zeitverschiebung zurückspringt.

Cron-Syntax: fünf Felder, Bereiche, Schritte und Listen

Ein Cron-Ausdruck plant wiederkehrende Jobs auf Unix-ähnlichen Systemen. Die Standardsyntax hat fünf durch Leerzeichen getrennte Felder: Minute (0-59), Stunde (0-23), Tag-des-Monats (1-31), Monat (1-12), Wochentag (0-7, wobei sowohl 0 als auch 7 Sonntag darstellen). Ein Sternchen (*) in einem Feld bedeutet "jeder gültige Wert". Der Ausdruck 30 8 * * 1-5 läuft um 08:30 Uhr von Montag bis Freitag. Bereiche verwenden einen Bindestrich: 1-5 umfasst die Werte 1, 2, 3, 4, 5. Listen verwenden Kommas: 1,15 bedeutet den 1. und 15. Schritte verwenden einen Schrägstrich: */15 im Minutenfeld bedeutet alle 15 Minuten (0, 15, 30, 45). Diese Kombinatoren können zusammen erscheinen: 0-30/10 bedeutet 0, 10, 20, 30. Cron hat kein Zeitzonenfeld. Der Daemon liest die Uhr der Maschine, auf der er läuft, die auf die lokale Zeitzone des Servers eingestellt ist. Wenn der Server UTC läuft, ein Entwickler aber Ortszeit erwartet, feuert der Zeitplan zur falschen Uhrstunde. Die praktische Regel ist, Cron-Zeitpläne als server-lokale-Zeit-Ausdrücke zu behandeln und die Zeitzone des Servers neben der Cron-Zeile zu dokumentieren.

Den Timestamp-Konverter lokal verwenden

Der Timestamp-Konverter auf Sunasty konvertiert in beide Richtungen: Epoch zu menschenlesbarem Datum und menschenlesbares Datum zurück zu Epoch. Man kann einen sekundengenauen oder einen millisekundengenauen Wert eingeben; das Tool erkennt die Einheit aus der Größenordnung. Es zeigt das Ergebnis in UTC und in der eigenen lokalen Zeitzone des Geräts nebeneinander, zusammen mit den rohen Sekunden- und Millisekundenwerten zum Kopieren. Eine Jetzt-Schaltfläche füllt den aktuellen Timestamp mit einem Klick ein, was eine schnelle Möglichkeit ist, die aktuelle Unix-Zeit zu prüfen, ohne ein Terminal zu öffnen. Einen eigenen Zeitzonenauswähler gibt es nicht: Die lokale Spalte spiegelt immer die Zeitzone wider, auf die Ihr Browser gerade eingestellt ist. All das läuft im Browser. Der Wert, den man in das Feld einfügt, wird von clientseitigem JavaScript gelesen und verlässt das Gerät nie.

Tools in diesem Artikel

Häufige Fragen

Warum verwendet JavaScript Millisekunden statt Sekunden?

JavaScripts Date-Objekt wurde von Anfang an für die Arbeit mit Subsekundengenauigkeit konzipiert, und Millisekunden bieten tausendmal die Auflösung von Sekunden ohne einen Dezimalpunkt zu benötigen. Der Kompromiss ist, dass Werte größer sind, weshalb Date.now() eine 13-stellige Zahl liefert, während die meisten serverseitigen Timestamps 10-stellig sind.

Müssen alle Server, auf denen Cron läuft, auf UTC eingestellt sein?

Nein, aber Server auf UTC zu betreiben ist eine verbreitete Praxis, weil sie die Mehrdeutigkeit beseitigt. Wenn ein Server auf UTC läuft, bedeutet ein Cron-Ausdruck wie 0 2 * * * genau 02:00 UTC und diese Zeit ist das ganze Jahr stabil. Auf einem Server in einer Zone, die Sommerzeit beobachtet, feuert derselbe Job im Sommer und Winter zu einem unterschiedlichen UTC-Zeitpunkt und kann beim Uhrenübergang zweimal feuern oder einmal ausfallen.

Was ist der sichere Speichertyp für Timestamps nach 2038?

Eine vorzeichenbehaftete 64-Bit-Ganzzahl speichert sekundengenaue Timestamps bis zum Jahr 292277026596, was weit über jede praktische Sorge hinausgeht. Die meisten aktuellen Datenbanken speichern Timestamps standardmäßig als 64-Bit-Werte. Wenn man mit einem Legacy-Schema oder einem binären Dateiformat arbeitet, das 32-Bit-Felder verwendet, ist die Migration zu 64-Bit-Speicher vor der 2038-Grenze die richtige Lösung.