Epoch / Unix Timestamp Konverter
Unix-Zeitstempel in lesbare Datumsangaben umwandeln und zurück, mit Zeitzonenunterstützung.
Aktueller Unix-Timestamp
Sekunden seit dem 1. Januar 1970 00:00:00 UTC
→ → Timestamp zu Datum
→ → Datum zu Timestamp
Was ist ein Unix-Timestamp?
Ein Unix-Timestamp (auch Epoch-Zeit, POSIX-Zeit oder Unix-Zeit genannt) ist die Anzahl der Sekunden, die seit dem 1. Januar 1970, 00:00:00 UTC vergangen sind — ein Referenzpunkt, der als Unix-Epoche bekannt ist. Dieses System wurde Ende der 1960er Jahre mit dem Unix-Betriebssystem eingeführt und hat sich seitdem zum universellen, sprachunabhängigen Standard für die Darstellung von Zeitpunkten in der Informatik entwickelt. Die Unix-Epoche wurde pragmatisch gewählt (sie lag kurz vor der weiten Verbreitung von Unix) und hat sich als bemerkenswert dauerhaft erwiesen: Stand Mitte 2025 liegt der aktuelle Unix-Timestamp bei etwa 1.748.000.000 — eine 10-stellige Zahl, die bequem in einen vorzeichenbehafteten 32-Bit-Integer bis zum 19. Januar 2038 passt und in einem 64-Bit-Integer über 292 Milliarden Jahre.
Das entscheidende Merkmal von Unix-Timestamps — und der Grund, warum sie die dominante Zeitdarstellung in Software bleiben — ist ihre Zeitzonenunabhängigkeit. Der Wert 1700000000 repräsentiert weltweit denselben absoluten Moment, unabhängig davon, ob der Beobachter in Berlin, Tokio oder New York sitzt. Dies eliminiert eine ganze Klasse von Bugs in verteilten Systemen: Zwei Server in verschiedenen Rechenzentren, die Unix-Timestamps vergleichen, beziehen sich auf denselben Referenzrahmen — ohne Ambiguität durch Sommerzeit-Offsets, UTC-Offsets oder lokale Zeitzonenkonventionen. Deshalb verwenden jede große Datenbank, jede Programmiersprache, jedes Betriebssystem und jede API Unix-Timestamps intern und konvertieren nur für die Anzeigeschicht in menschenlesbare Ortszeit.
In der Praxis begegnen Softwareentwickler zwei eng verwandten Timestamp-Formaten: Sekunden-Timestamps (10 Stellen, z. B. 1700000000) und Millisekunden-Timestamps (13 Stellen, z. B. 1700000000000). JavaScripts Date.now() und die meisten Browser-APIs liefern Millisekunden; Linuxs time(), PostgreSQL und die meisten serverseitigen Sprachen verwenden standardmäßig Sekunden; einige Finanz- und Distributed-Tracing-Systeme nutzen Mikrosekunden (16 Stellen) oder Nanosekunden (19 Stellen). Der ISO-8601-Standard (und sein Internet-Profil RFC 3339) liefert das menschenlesbare Gegenstück: Strings wie 2025-04-15T14:30:00Z oder 2025-04-15T14:30:00+02:00 mit expliziten Zeitzoneninformationen. XRechnung und ZUGFeRD verwenden das JJJJ-MM-TT-Subset von ISO 8601 für Rechnungsdaten, Lieferdaten und Fälligkeitsdaten — niemals Unix-Timestamps — weil menschenlesbare Strings für Rechtsdokumente erforderlich sind.
So verwenden Sie diesen Konverter
- Live-Epoch-Zähler — Der große Zähler oben zeigt den aktuellen Unix-Timestamp in Sekunden, der jede Sekunde aktualisiert wird. Klicken Sie auf „Kopieren", um den aktuellen Timestamp für eine Datenbankabfrage, einen API-Aufruf oder eine Log-Suche zu übernehmen.
- Timestamp → Datum — Fügen Sie einen Unix-Timestamp ein (Sekunden oder Millisekunden — das Tool erkennt die Einheit automatisch anhand der Stellenzahl) und klicken Sie auf Konvertieren, um Datum und Uhrzeit in menschenlesbarer Form in Ihrer gewählten Zeitzone zu sehen.
- Datum → Timestamp — Wählen Sie Datum und Uhrzeit über die Datumsauswahl und konvertieren Sie in einen Unix-Timestamp in Sekunden und Millisekunden. Nützlich für die Konstruktion von API-Query-Parametern oder SQL-WHERE-Klauseln mit Zeitgrenzen.
- Zeitzonenauswahl — Wählen Sie aus 8 gängigen Zeitzonen, darunter UTC, Europe/Berlin (mit automatischer MEZ/MESZ-Behandlung), America/New_York, America/Los_Angeles, Asia/Tokyo und weiteren. Alle Sommerzeitübergänge werden automatisch von der Intl-API des Browsers behandelt.
Alle Timestamp-Berechnungen laufen vollständig in Ihrem Browser mithilfe von JavaScripts nativem Date-Objekt und der Intl.DateTimeFormat-API. Es werden keine Daten an einen Server übertragen.
Wie es funktioniert
Timestamps werden mit JavaScripts nativem Date-Objekt verarbeitet. Der Eingabe-String wird zunächst anhand der Stellenzahl geprüft: 10 Stellen (Bereich 1.000.000.000 bis 9.999.999.999) werden als Sekunden behandelt und vor der Date-Konstruktion mit 1000 multipliziert; 13 Stellen werden direkt als Millisekunden verwendet. Sonderfälle wie 0 (Unix-Epoche) und negative Werte (vor 1970) werden vom Date-Konstruktor verarbeitet. Die Intl.DateTimeFormat-API — die die im Browser eingebaute IANA-Zeitzonendatenbank nutzt — formatiert den resultierenden Zeitpunkt in der gewählten Zeitzone und wendet dabei automatisch die korrekten UTC-Offsets und Sommerzeitregeln für das jeweilige Datum an.
Für die Umkehrung (Datum zu Timestamp) liest das Tool die datetime-local-Eingabe als ISO-8601-Ortszeit-String (z. B. 2025-04-15T14:30). Da datetime-local-Eingaben keine Zeitzonendaten enthalten, interpretiert unser Tool den Wert als in der aktuell gewählten Zeitzone liegend. Es konstruiert ein Date-Objekt durch Anwenden des Zeitzonenoffsets, um das UTC-Äquivalent zu erhalten, ruft dann getTime() auf (liefert Millisekunden) und teilt durch 1000 für den Sekunden-Timestamp. Beide Werte werden angezeigt, sodass Sie denjenigen kopieren können, den Ihr Zielsystem erwartet.
Der Live-Zähler verwendet setInterval mit einem 1000-ms-Intervall, um jede Sekunde Math.floor(Date.now()/1000) aufzurufen und die Anzeige zu aktualisieren. Da Date.now() die Systemuhr des Browsers liest, entspricht der angezeigte Timestamp der Uhr Ihres Computers — nicht einem Remote-NTP-Server. Wenn Ihre Systemuhr erheblich von UTC abweicht, spiegelt der angezeigte Timestamp diese Abweichung wider. Halten Sie für Produktionssysteme die Server-Uhren mithilfe von NTP oder PTP (Precision Time Protocol) synchronisiert.
Anwendungsfälle
Datenbankabfragen debuggen
SQL- und NoSQL-Abfragen umfassen häufig Timestamp-Vergleiche. PostgreSQL speichert TIMESTAMPTZ-Werte intern als Unix-Mikrosekunden seit 2000-01-01, während MySQL TIMESTAMP Sekunden seit 1970 speichert. Beim Inspizieren roher Datenbankwerte mit SELECT EXTRACT(EPOCH FROM created_at) oder beim Blick auf MongoDB-ISODate-Interna übersetzt unser Konverter den rohen Integer sofort in ein menschenlesbares Datum.
REST-API- und Webhook-Debugging
GitHub, Stripe, AWS CloudWatch und Hunderte anderer APIs liefern Unix-Timestamps in JSON-Payloads — für created_at, updated_at, expires_at, last_seen und ähnliche Felder. Fügen Sie den Timestamp-Wert direkt aus einer JSON-Antwort ein, um das entsprechende Datum zu sehen, ohne manuell rechnen zu müssen.
Log-Datei- und Observability-Analyse
Nginx-Access-Logs, syslog-Einträge, Datadog- und Grafana-Metriken sowie Distributed-Tracing-Spans verwenden Unix-Timestamps oder Millisekunden-Timestamps ausgiebig. Beim Korrelieren eines Vorfalls über mehrere Log-Quellen ist das Konvertieren der Timestamps in eine gemeinsame Zeitzone (vorzugsweise UTC) essenziell. Unser Tool hilft auch beim Prüfen, ob ein Token oder eine Session abgelaufen ist, indem das exp-Feld (Unix-Timestamp) mit der aktuellen Zeit verglichen wird.
XRechnung- und Rechnungsdaten-Konvertierung
XRechnung schreibt ISO-8601-Datumsstrings (JJJJ-MM-TT) für BT-2 (Rechnungsdatum), BT-72 (Beginn des Lieferzeitraums) und BT-9 (Fälligkeitsdatum) vor. Wenn Ihr Abrechnungssystem Unix-Timestamps generiert, erzeugt unser Konverter exakt den benötigten ISO-8601-Datumsstring. Der UTC-Tab ist die richtige Wahl — XRechnung-Daten referenzieren Kalenderdaten ohne Zeitkomponente, und das Ableiten des Datums aus UTC verhindert sommerzeitbedingte Tagesdifferenzfehler.
Beispiel: Timestamp-Konvertierung
Hier sehen Sie, wie der Unix-Timestamp 1700000000 in verschiedene Zeitzonen-Darstellungen umgerechnet wird. Alle vier Zeilen beziehen sich auf denselben absoluten Moment in der Zeit — nur die lokale Uhrzeitanzeige unterscheidet sich:
Unix-Timestamp (Sekunden): 1700000000 Unix-Timestamp (Millisekunden): 1700000000000 Zeitzonenkonvertierungen: UTC: 2023-11-14T22:13:20Z Europe/Berlin: 2023-11-15T00:13:20+01:00 (MEZ, UTC+1 im November) America/New_York: 2023-11-14T17:13:20-05:00 (EST, UTC-5) Asia/Tokyo: 2023-11-15T07:13:20+09:00 (JST, UTC+9) Als XRechnung-Rechnungsdatum (UTC-Kalenderdatum): 2023-11-14 Hinweis: Berliner Datum ist 2023-11-15 — die Zeitzone ist entscheidend!
Beachten Sie, dass das Kalenderdatum zwischen UTC (14. Nov.) und Berlin (15. Nov.) abweicht, weil der Timestamp nach Mitternacht Berliner Zeit liegt. Für XRechnung leiten Sie das Rechnungsdatum stets aus der UTC-Darstellung ab, um Tagesdifferenzfehler zu vermeiden.
Tipps & Einschränkungen
Tipps
- Unser Tool erkennt automatisch, ob ein Timestamp in Sekunden (10 Stellen) oder Millisekunden (13 Stellen) ist. Wenn Sie ein unplausibles Datum sehen (Jahr 1970 oder Jahr 59999), liegt möglicherweise eine falsche Einheit vor — versuchen Sie, durch 1000 zu teilen oder mit 1000 zu multiplizieren.
- Speichern Sie Timestamps immer in UTC in Datenbanken und Anwendungsstatus. Konvertieren Sie nur für die Anzeige in die lokale Zeitzone — das ist die wirksamste Praxis zur Vermeidung sommerzeitbedingter Bugs in verteilten Systemen.
- Für XRechnung-kompatible Datumsstrings (JJJJ-MM-TT) verwenden Sie das UTC-Konvertierungsergebnis. Wenn der Timestamp nach Mitternacht UTC, aber vor Mitternacht in der lokalen Zeitzone der Rechnung liegt, weichen die Daten ab — eine häufige Ursache für Tagesdifferenzfehler bei der Rechnungserstellung.
- Der Live-Zähler kann direkt kopiert und als WHERE-Klausel-Grenzwert in SQL (WHERE created_at > 1700000000), als Cache-Busting-Query-Parameter (?v=1700000000) oder als Log-Such-Timestamp verwendet werden.
Einschränkungen
- Das Tool unterstützt 8 gängige Zeitzonen. Für andere IANA-Zeitzonen (z. B. Asia/Kolkata, Pacific/Auckland) verwenden Sie die datetime-Bibliothek Ihrer Programmiersprache oder das native Intl.DateTimeFormat des Browsers mit dem vollständigen IANA-Namen.
- Nanosekunden-Timestamps (19 Stellen, verwendet in Hochfrequenzhandel, Netzwerkprotokollen und einigen CNCF-Observability-Tools) werden nicht unterstützt. Verwenden Sie spezialisierte Bibliotheken (z. B. time.time_ns() in Python, time.Now().UnixNano() in Go) für Nanosekunden-Präzision.
- Negative Timestamps (Daten vor dem 1. Januar 1970) werden vom JavaScript-Date-Objekt und unserem Konverter unterstützt, aber viele Legacy-Systeme, 32-Bit-Integer und ältere Datenbanken verarbeiten sie möglicherweise nicht korrekt.
- Die Genauigkeit hängt von der Systemuhr des Browsers ab, die in der Regel mit NTP synchronisiert ist, aber um einige Hundert Millisekunden abweichen kann. Für Millisekunden-Präzisionsanforderungen in der Produktion synchronisieren Sie die Systemuhr mit einem NTP-Client (chrony, ntpd) oder dem Zeitdienst Ihres Cloud-Anbieters.
Häufig gestellte Fragen
Was ist das Jahr-2038-Problem und betrifft es moderne Systeme?
Systeme, die Unix-Timestamps als vorzeichenbehaftete 32-Bit-Integer speichern, laufen am 19. Januar 2038 um 03:14:07 UTC über — dem Moment, in dem der Wert 2.147.483.647 (der maximale positive 32-Bit-Integer) überschritten wird. Der Timestamp springt auf -2.147.483.648, was dem 13. Dezember 1901 entspricht, und Datumsberechnungen liefern völlig falsche Ergebnisse. Moderne 64-Bit-Systeme mit int64 sind bis zum Jahr 292.277.026.596 n. Chr. sicher. Risikogebiete: Legacy-Embedded-Systeme (Industriesteuerungen, ältere Router), MySQL-TIMESTAMP-Spalten (32-Bit-Speicher, Maximalwert 2038-01-19) und Anwendungscode, der Timestamps in einem 32-Bit-Integer-Typ speichert.
Was ist der Unterschied zwischen Sekunden- und Millisekunden-Timestamps?
Ein Sekunden-Timestamp hat 10 Stellen (Bereich: 0 bis ~9,9 Milliarden, entspricht den Jahren 1970 bis 2286). Ein Millisekunden-Timestamp hat 13 Stellen (der Sekundenwert multipliziert mit 1000, plus die Millisekunden). JavaScripts Date.now() gibt Millisekunden zurück. Unix-Systemaufrufe (time(), gettimeofday()), Pythons time.time() und die meisten Datenbanksysteme verwenden standardmäßig Sekunden. Redis EXPIREAT akzeptiert Sekunden; Redis PEXPIREAT Millisekunden. Unser Tool erkennt die Einheit automatisch aus der Stellenzahl.
Warum referenzieren Timestamps immer UTC?
UTC (Koordinierte Weltzeit) bietet einen einzigen, eindeutigen Referenzrahmen, auf den sich alle Uhren weltweit beziehen können. Durch das Speichern und Übertragen von Zeiten in UTC und das Konvertieren in Ortszeit nur für die Anzeige vermeiden Systeme die drei häufigsten zeitbezogenen Bugs: (1) Sommerzeit-Ambiguität — Uhren werden im Herbst eine Stunde zurückgestellt, was ein einstündiges Fenster lokaler Zeiten doppelt erscheinen lässt; (2) Zeitzonenregel-Änderungen — Regierungen ändern Zeitzonenregeln und historische Daten müssen die damals geltenden Regeln widerspiegeln; (3) Zeitzonenübergreifende Vergleichsfehler — der Vergleich zweier lokaler Timestamps aus verschiedenen Zeitzonen ohne Berücksichtigung der Offsets.
Können Unix-Timestamps Daten vor 1970 darstellen?
Ja — negative Unix-Timestamps repräsentieren Momente vor der Unix-Epoche. Zum Beispiel repräsentiert -86400 den 31.12.1969 um 23:59:59 UTC, und -2208988800 den 01.01.1900 um 00:00:00 UTC. Das JavaScript-Date-Objekt und die meisten 64-Bit-Bibliotheken verarbeiten negative Timestamps korrekt. Viele Datenbanksysteme (MySQL TIMESTAMP, frühere PostgreSQL-Versionen) unterstützen keine negativen Timestamps — verwenden Sie dort einen DATE- oder DATETIME-Spaltentyp. Historische Daten in Finanz- und Rechtsdokumenten (vor 1970) werden typischerweise als ISO-8601-Strings gespeichert.
Was ist der Unterschied zwischen Unix-Zeit und ISO 8601?
Unix-Zeit ist eine Ganzzahl (oder Dezimalzahl für Sub-Sekunden-Präzision), die Sekunden seit 1970-01-01T00:00:00Z zählt. Sie ist kompakt, arithmetisch praktisch und zeitzonenfrei. ISO 8601 ist ein menschenlesbares String-Format, das von der ISO für Datum- und Zeitdarstellungen standardisiert wurde: 2025-04-15 (nur Datum), 2025-04-15T14:30:00Z (UTC-Datetime) oder 2025-04-15T16:30:00+02:00 (Datetime mit explizitem Offset). RFC 3339 ist ein Internet-Profil von ISO 8601, das in IETF-Protokollen und APIs verwendet wird. XRechnung nutzt das JJJJ-MM-TT-Format für alle Rechnungsdatumsfelder, weil Rechtsdokumente menschenlesbare, zeitzoneindeutige Daten erfordern.
Wie wirkt sich die Sommerzeit (DST) auf Timestamp-Konvertierungen aus?
Unix-Timestamps selbst sind nie von der Sommerzeit betroffen — sie sind stets UTC-basierte absolute Zählungen. DST ist nur relevant, wenn Sie einen Timestamp für die Anzeige in Ortszeit konvertieren. Derselbe Unix-Timestamp kann im Januar als 14:00 MEZ (UTC+1) und im Juli als 15:00 MESZ (UTC+2) in der Zeitzone Europe/Berlin angezeigt werden. Wenn Sie einen „Berliner Mitternacht"-Timestamp für ein Sommerdatum berechnen, müssen Sie UTC+2 verwenden, nicht UTC+1. Das Intl.DateTimeFormat-Backend unseres Tools nutzt die vollständige IANA-Zeitzonendatenbank und wendet automatisch den korrekten Sommerzeitoffset für das jeweilige Datum an.
Welches Zeitstempelformat verwendet XRechnung?
XRechnung verwendet ISO-8601-Datumsstrings im Format JJJJ-MM-TT für BT-2 (Rechnungsdatum), BT-72/73 (Beginn/Ende des Lieferzeitraums) und BT-9 (Fälligkeitsdatum). Das sind Kalenderdaten ohne Zeitkomponente. XRechnung verwendet keine Unix-Timestamps in irgendwelchen Feldern. Beim Generieren von XRechnung aus einem Abrechnungssystem, das Unix-Timestamps speichert, leiten Sie den Datumsstring stets aus dem UTC-Kalenderdatum (JJJJ-MM-TT) ab. Wichtig: Fällt der Timestamp nach Mitternacht UTC, aber vor Mitternacht in der lokalen Zeitzone, weichen UTC-Datum und lokales Datum ab — bei grenzüberschreitenden Transaktionen kann das zu Datumsfehlern führen.
Wie präzise ist ein Unix-Timestamp?
Ein Standard-Unix-Timestamp in Sekunden bietet 1-Sekunden-Präzision — ausreichend für die meisten Geschäfts- und Logging-Anwendungsfälle. Millisekunden-Timestamps (verwendet in JavaScript, vielen REST-APIs und Javas System.currentTimeMillis()) bieten 1-ms-Präzision. Hochauflösende Timestamps in Linux (clock_gettime(CLOCK_REALTIME)) und Gos time.Now().UnixNano() bieten Nanosekunden-Auflösung, obwohl die tatsächliche Hardware-Taktgenauigkeit typischerweise 1–100 Mikrosekunden beträgt. Für Finanztransaktionen und Hochfrequenzhandel sind Nanosekunden-Timestamps und PTP-Synchronisation (Precision Time Protocol) Standard.
Was ist der Unix-Timestamp für ein bestimmtes Datum und eine bestimmte Uhrzeit?
Verwenden Sie den Abschnitt „Datum zu Timestamp": Wählen Sie Zieldatum und -uhrzeit in der Datumsauswahl, wählen Sie die passende Zeitzone und klicken Sie auf Konvertieren. Das Tool liefert sowohl den Sekunden- als auch den Millisekunden-Timestamp. Alternativ in JavaScript: new Date('2025-12-31T00:00:00Z').getTime() / 1000 ergibt den UTC-Mitternacht-Sekunden-Timestamp für den 31. Dezember 2025. In Python: datetime.datetime(2025, 12, 31, tzinfo=datetime.timezone.utc).timestamp(). In SQL (PostgreSQL): SELECT EXTRACT(EPOCH FROM TIMESTAMP WITH TIME ZONE '2025-12-31 00:00:00+00').
Kann ich Timestamps in einer Datenbank als Unix-Integer speichern?
Das hängt von Ihren Anforderungen ab. Native Timestamp-Typen (TIMESTAMP WITH TIME ZONE in PostgreSQL, DATETIME(6) in MySQL 5.6+) werden empfohlen, weil sie sich in die Datums-Arithmetik-Funktionen der Datenbank integrieren, in Abfrageergebnissen lesbar angezeigt werden und zeitzonenbewusste Vergleiche korrekt unterstützen. Das Speichern von UTC-Unix-Timestamps in einer BIGINT-Spalte ist jedoch ein valides, hochportables Muster, das in vielen Hochleistungssystemen verwendet wird — es vermeidet jede DST- oder Zeitzonenbehandlung auf Datenbankebene und funktioniert identisch in PostgreSQL, MySQL, SQLite und DynamoDB. Dokumentieren Sie die Spalte als „UTC-Unix-Timestamp in Sekunden" oder „Millisekunden" und fügen Sie die Einheitenumrechnung auf Anwendungsebene hinzu.