🧰 ToolPicoAlle Tools →
Startseite » Blog » Epoch-Zeitstempel im Code parsen

Epoch-Zeitstempel im Code parsen: Ein Sprachen-Guide für Entwickler

JavaScript, Python, PHP und SQL sind nicht die einzigen Orte, an denen ein Unix-Zeitstempel geparst werden muss. Wer an einem Java-Backend, einem Go-Microservice, einer C#-API oder einem PowerShell-Skript arbeitet, braucht andere Syntax — und stößt gelegentlich sogar auf einen Zeitstempel in Hexadezimal-Notation. Dieser Guide zeigt, wie du Epoch-Werte über verschiedene Sprachen und Datenbanken hinweg korrekt interpretierst.

Inhalt

Warum jede Sprache ihre eigene Epoch-Syntax hat

Kurz gesagt: Der Epoch-Wert selbst ist immer dieselbe Zahl — nur die Funktion oder Klasse, die ihn in ein nutzbares Datumsobjekt umwandelt, unterscheidet sich je nach Sprache und Laufzeitumgebung.

Ein Beispiel-Szenario: Angenommen, du bekommst von einem externen Dienst den Zeitstempel 1753267200 als Teil einer JSON-Antwort zurück. In JavaScript reicht new Date(epoch * 1000), weil Date Millisekunden erwartet. Portierst du dieselbe Logik unreflektiert nach Java oder Go, scheitert sie — dort heißen die Einstiegspunkte anders und erwarten teils Sekunden, teils Millisekunden als separate Parameter. Wer zwischen Backend-Sprachen wechselt, muss diese Unterschiede kennen, sonst entstehen Off-by-1000-Fehler oder Daten, die scheinbar im Jahr 1970 liegen.

Kompilierte Sprachen: Java, C# und Go

Kurz gesagt: Java nutzt Instant.ofEpochSecond(), C# nutzt DateTimeOffset.FromUnixTimeSeconds(), Go nutzt time.Unix() — alle drei geben ein zeitzonenbewusstes Objekt zurück, das du danach formatierst.

In Java ist der moderne Weg über das java.time-Paket: Instant.ofEpochSecond(1753267200) liefert einen Zeitpunkt in UTC, den du mit .atZone(ZoneId.of("Europe/Berlin")) in eine bestimmte Zeitzone überführst. Für Millisekunden-Werte gibt es Instant.ofEpochMilli(...). Ältere Codebasen verwenden manchmal noch new Date(millis) — hier ist Vorsicht geboten, weil dieser Konstruktor Millisekunden erwartet, nicht Sekunden.

In C# (.NET) liefert DateTimeOffset.FromUnixTimeSeconds(1753267200) direkt ein DateTimeOffset-Objekt inklusive UTC-Bezug, das sich mit .ToLocalTime() oder TimeZoneInfo.ConvertTime(...) weiterverarbeiten lässt. Für Millisekunden gibt es das Pendant FromUnixTimeMilliseconds(...).

In Go nutzt du das Standardpaket time: time.Unix(1753267200, 0) — der zweite Parameter ist der Nanosekunden-Anteil, meist 0, wenn du nur Sekunden hast. Das Ergebnis ist ein time.Time-Wert, den du mit .UTC() oder .In(loc) in die gewünschte Zeitzone bringst und mit .Format(...) ausgibst.

Praxis-Hinweis: Diese drei Sprachen werden vom Code-Snippet-Generator des Unix-Zeitstempel-Umwandlers derzeit nicht direkt mit ausgegeben (aktuell abgedeckt: JavaScript, Python, PHP, SQL und Google Sheets) — eine Erweiterung um Java, C#, Go, Ruby, PowerShell und Bash ist eine denkbare künftige Ausbaustufe des Tools. Bis dahin hilft die manuelle Übertragung der oben gezeigten Muster.

Skript- und Shell-Umgebungen: Ruby, PowerShell und Bash

Kurz gesagt: Ruby nutzt Time.at(), PowerShell nutzt [DateTimeOffset]::FromUnixTimeSeconds(), Bash/GNU-date nutzt date -d @epoch — praktisch, um einen einzelnen Wert schnell im Terminal zu prüfen.

In Ruby erzeugt Time.at(1753267200) ein Time-Objekt in der Systemzeitzone; mit .utc erzwingst du UTC, mit .strftime("%d.%m.%Y %H:%M") formatierst du das Ergebnis lesbar.

In PowerShell (etwa unter Windows) liefert [DateTimeOffset]::FromUnixTimeSeconds(1753267200).UtcDateTime ein DateTime-Objekt in UTC — praktisch für Admin-Skripte, die Log-Zeitstempel aus einer API oder Textdatei auswerten.

In Bash unter Linux/macOS ist die GNU-Variante date -d @1753267200, während macOS/BSD date -r 1753267200 erwartet — ein häufiger Stolperstein, wenn ein Skript zwischen beiden Systemen portiert wird. Beispiel-Szenario: Ein Deploy-Skript soll den Build-Zeitpunkt aus einer BUILD_EPOCH-Umgebungsvariable lesbar ins Log schreiben — je nach Zielsystem (Linux-CI oder Mac-Entwicklerrechner) braucht es die passende Flag-Variante.

Datenbanken: PostgreSQL, MySQL und SQLite im Vergleich

Kurz gesagt: PostgreSQL nutzt to_timestamp(), MySQL nutzt FROM_UNIXTIME(), SQLite nutzt datetime(epoch, 'unixepoch') — alle drei erwarten Sekunden, nicht Millisekunden.
DatenbankFunktion (Beispiel)Erwartete Einheit
PostgreSQLto_timestamp(epoch)Sekunden
MySQLFROM_UNIXTIME(epoch)Sekunden
SQLitedatetime(epoch, 'unixepoch')Sekunden

Hinweis: Konkrete Syntax kann je nach Datenbankversion leicht abweichen — die Tabelle zeigt die gängigsten, aktuellen Varianten zur Orientierung.

Ein typisches Beispiel-Szenario: Eine Spalte created_at_ms speichert Millisekunden-Zeitstempel aus einer Node.js-Anwendung. Beim Auslesen in PostgreSQL musst du zuerst durch 1000 teilen: to_timestamp(created_at_ms / 1000.0) — sonst interpretiert die Datenbank die Zahl fälschlich als Sekunden und liefert ein Datum weit in der Zukunft.

Wenn der Zeitstempel hexadezimal vorliegt

Kurz gesagt: Manche Log-Formate, Netzwerkprotokolle oder Binärdaten speichern den Epoch-Wert als Hexadezimalzahl statt als Dezimalzahl — vor der eigentlichen Umwandlung muss er zuerst ins Dezimalsystem übersetzt werden.

Ein Beispiel-Szenario: In einem rohen Netzwerk-Log oder einem Binärdump taucht der Wert 65731D80 auf. Das ist keine willkürliche Zeichenkette, sondern ein Unix-Zeitstempel in Hexadezimal-Darstellung (Basis 16) — umgerechnet ins Dezimalsystem ergibt er eine gewöhnliche Epoch-Sekundenzahl, die sich anschließend wie gewohnt in ein Datum umwandeln lässt.

Zwei-Schritt-Ansatz: Erst die Hex-Zeichenkette in eine Dezimalzahl umwandeln (etwa mit einem Hex-zu-Dezimal-Rechner), danach das Ergebnis als gewöhnlichen Epoch-Sekundenwert in den Reiter „Epoch → Datum“ einfügen. Aktuell ist dieser erste Umwandlungsschritt kein eingebauter Teil des Genauigkeits-Auswahlmenüs im Unix-Zeitstempel-Umwandler — ein direkter Hex-Modus innerhalb der bestehenden Genauigkeits-Auswahl (neben Sekunden/Millisekunden/Mikrosekunden/Nanosekunden) wäre ein denkbarer künftiger Komfortgewinn, der den Umweg über ein separates Hex-Tool erspart.

Bis eine solche direkte Unterstützung existiert, bleibt der Zwei-Schritt-Weg zuverlässig: Hex-zu-Dezimal-Umwandlung, dann Epoch-zu-Datum-Umwandlung — beides lässt sich in wenigen Sekunden nacheinander erledigen.

Häufig gestellte Fragen

Wie parse ich einen Unix-Zeitstempel in Java?
In modernem Java verwendest du meist Instant.ofEpochSecond(epochSekunden) oder Instant.ofEpochMilli(epochMillisekunden) aus dem java.time-Paket, um daraus ein Instant-Objekt zu erzeugen, das du anschließend mit ZoneId in eine ZonedDateTime für eine bestimmte Zeitzone umwandeln kannst. Ältere Codebasen nutzen teils noch new Date(epochMillisekunden), was Millisekunden statt Sekunden erwartet — eine häufige Fehlerquelle.
Wie wandle ich einen Epoch-Wert in Go oder C# um?
In Go nutzt du time.Unix(sekunden, nanosekunden) aus dem time-Paket, um ein time.Time-Objekt zu erhalten. In C# verwendest du DateTimeOffset.FromUnixTimeSeconds(epochSekunden) oder FromUnixTimeMilliseconds(epochMillisekunden), was direkt ein DateTimeOffset mit UTC-Bezug liefert, das du danach in eine gewünschte Zeitzone konvertieren kannst.
Kann ich einen Unix-Zeitstempel direkt aus der Kommandozeile umwandeln?
Ja. Unter Linux/macOS mit Bash reicht meist date -d @epochSekunden (GNU date) oder date -r epochSekunden (BSD/macOS date). Unter Windows mit PowerShell nutzt du [DateTimeOffset]::FromUnixTimeSeconds(epochSekunden).UtcDateTime. Beide Wege sind praktisch, wenn du schnell einen einzelnen Wert in einem Terminal prüfen willst, ohne eine Datei zu öffnen.
Was ist ein hexadezimaler Unix-Zeitstempel, und wo taucht er auf?
Manche Systeme, Log-Formate und Netzwerkprotokolle speichern den Epoch-Wert nicht als Dezimalzahl, sondern als Hexadezimalzahl (Basis 16), zum Beispiel 65731D80 statt 1701234816. Das spart oft Speicherplatz oder passt sich an ein binäres Datenformat an. Um einen solchen Wert zu prüfen, wandelst du ihn zunächst mit einem Hex-zu-Dezimal-Rechner in eine Dezimalzahl um, bevor du ihn als Epoch-Sekunden interpretierst.
Warum unterscheiden sich Datenbank-Funktionen wie PostgreSQL, MySQL und SQLite beim Umgang mit Epoch-Werten?
Jedes Datenbanksystem hat eigene Funktionsnamen und Erwartungen an die Einheit. PostgreSQL nutzt to_timestamp(epochSekunden) und erwartet Sekunden (ggf. mit Nachkommastellen). MySQL verwendet FROM_UNIXTIME(epochSekunden), ebenfalls in Sekunden. SQLite speichert Datumswerte oft als Text oder Float und nutzt datetime(epochSekunden, 'unixepoch') mit dem Zusatz 'unixepoch', damit die Funktion die Zahl korrekt interpretiert. Millisekunden-Werte müssen in allen drei Fällen vorher durch 1000 geteilt werden.

Wandle Epoch-Werte direkt im Browser um — mit Zeitzonen, Sammelumwandlung und fertigen Code-Snippets in JavaScript, Python, PHP, SQL und Google Sheets.

Zum Unix-Zeitstempel-Umwandler →

Verwandte Ratgeber

Methodischer Hinweis: Dieser Ratgeber richtet sich an Entwickler, die Epoch-Werte in verschiedenen Programmiersprachen und Datenbanken verarbeiten. Code-Beispiele dienen der Veranschaulichung von Syntax-Mustern und sollten vor produktivem Einsatz gegen die jeweils aktuelle Sprachdokumentation geprüft werden.