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.
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.
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.
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.
to_timestamp(), MySQL nutzt FROM_UNIXTIME(), SQLite nutzt datetime(epoch, 'unixepoch') — alle drei erwarten Sekunden, nicht Millisekunden.| Datenbank | Funktion (Beispiel) | Erwartete Einheit |
|---|---|---|
| PostgreSQL | to_timestamp(epoch) | Sekunden |
| MySQL | FROM_UNIXTIME(epoch) | Sekunden |
| SQLite | datetime(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.
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.
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.
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.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.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.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 →