Die sieben Fehler, die ein falsches Datum erzeugen
Ein Epoch-Konverter macht einfache Arithmetik, also ist bei falscher Ausgabe fast nie die Mathematik die Ursache — es ist die Eingabe. Ein Timestamp trägt kein Etikett, das verrät, ob er Sekunden oder Millisekunden, UTC oder lokal ist oder wie präzise er ist, und jede falsche Umwandlung entsteht dadurch, dass man eines davon falsch errät. Der schnellste Hinweis ist das resultierende Jahr: ein Datum nahe 1970 oder Tausende Jahre in der Zukunft ist eine Einheiten-Verwechslung, und ein Datum, das stimmt, aber um eine runde Stundenzahl daneben liegt, ist ein Zeitzonenfehler. Die Tabelle unten ist der Feldführer; die Abschnitte danach erklären die Einheiten- und Zeitzonenfehler ausführlich und zeigen, wie man eine Umwandlung im Code prüft.
| Fehler | Was du siehst | Ursache | Behebung |
|---|---|---|---|
| Sekunden als Millisekunden gelesen | Datum landet in 1970 | JS Date und Date.now() erwarten ms; du hast 10-stellige Sekunden übergeben | Sekunden mit 1000 multiplizieren |
| Millisekunden als Sekunden gelesen | Datum Tausende Jahre in der Zukunft | 13-stelliger Wert an eine Sekunden-Funktion übergeben | Zuerst durch 1000 teilen |
| UTC als lokale Zeit angezeigt | Richtiger Tag, Uhr um deinen Offset verschoben | Konverter hat standardmäßig eine andere Zeitzone gewählt | Konverter auf UTC stellen |
| Lokale Zeit ohne ihren Offset kopiert | Auf einer anderen Maschine um Stunden daneben | Eine Wanduhrzeit ohne Zone gespeichert | UTC plus die Zeitzone speichern |
| Sommerzeit-mehrdeutige Wanduhrzeit | Nahe einer Umstellung um genau eine Stunde daneben | Eine lokale Zeit, die zweimal oder nie vorkommt | Aus UTC umwandeln; die IANA-Zone festlegen |
| Mikro-/Nanosekunden als Sekunden gelesen | Datum weit in der Zukunft (16 oder 19 Stellen) | Datenbank- oder Tracing-Wert in µs oder ns | Durch 1.000.000 (µs) oder 1.000.000.000 (ns) teilen |
| Der angezeigten Präzision vertrauen | Sekundenbruchteil still verworfen | Konverter hat die Millisekunden gekürzt | Die von der Ziel-API dokumentierte Einheit bestätigen |
Was ein Epoch-Konverter tut
Ein Epoch-Konverter wandelt numerische Timestamps in lesbare Daten um und menschliche Daten zurück in Epoch-Timestamps. Ein guter verarbeitet Unix-Sekunden, Unix-Millisekunden, UTC-Ausgabe, lokale Zeitzonenausgabe und ISO-8601-Zeichenketten und macht die Einheit offensichtlich, bevor du einen Wert in Code, eine Datenbank oder eine API-Anfrage kopierst. Epoch-Konverter, Unix-Zeit-Konverter, Unix-Timestamp-Konverter und Unix-Epoch-Rechner beschreiben alle dieselbe Aufgabe: zwischen einem Zählwert von Sekunden (oder Millisekunden) seit dem 1. Januar 1970 UTC und einem für Menschen lesbaren Datum übersetzen. Der Konverter ist selten das Problem — meist ist es die Eingabe.
Die Einheitenfehler: Sekunden, Millisekunden, Mikro, Nano
Der mit Abstand häufigste Umwandlungsfehler ist eine Einheiten-Verwechslung, und sie hat eine Signatur: Das Datum landet in 1970 oder Tausende Jahre entfernt. In JavaScript schlägt sie am häufigsten zu, weil sowohl der Date-Konstruktor als auch Date.now() in Millisekunden arbeiten, während die meisten APIs, Datenbanken und der Unix-Befehl date in Sekunden arbeiten. Übergib einen 10-stelligen Sekundenwert an new Date(), ohne mit 1000 zu multiplizieren, und du landest 53 Jahre zu früh. Umgekehrt — 13-stellige Millisekunden an eine Sekunden-Funktion zu füttern — schleudert das Datum weit in die Zukunft. Höher aufgelöste Quellen verschärfen es: Datenbanken liefern oft 16-stellige Mikrosekunden und Tracing-Systeme 19-stellige Nanosekunden, und beide sehen wie ein gültiger Unix-Wert aus, bis sie ins falsche Jahrtausend dekodieren.
- 10 Stellen → Sekunden (z. B. 1700000000); 13 → Millisekunden; 16 → Mikrosekunden; 19 → Nanosekunden
- JavaScript: new Date(seconds * 1000), oder new Date(ms) direkt
- Mikrosekunden → vor der Umwandlung durch 1.000.000 teilen; Nanosekunden → durch 1.000.000.000
- Plausibilitätsprüfung: Das Ergebnis sollte ein glaubwürdiges Datum im aktuellen Jahrzehnt sein
Die Zeitzonenfehler: UTC vs. lokal und Sommerzeit
Sobald die Einheit stimmt, sind die verbleibenden Fehler Zeitzonenfehler, und auch sie teilen eine Signatur: Das Datum ist richtig, aber die Uhr ist um eine ganze Stundenzahl verschoben. Ein Unix-Timestamp ist ein einzelner Zeitpunkt ohne eigene Zeitzone; der Offset wird erst beim Formatieren des Zeitpunkts angewendet. Zwei Konverter mit unterschiedlichen Zeitzonen zeigen also für dieselbe Zahl unterschiedliche Uhrzeiten — keiner ist falsch, sie zeigen nur verschiedene lokale Sichten. Die Falle ist, eine lokale Wanduhrzeit zu kopieren, ohne festzuhalten, aus welcher Zone sie stammt, oder eine Zeit umzuwandeln, die auf eine Sommerzeitumstellung fällt, wo eine lokale Zeit zweimal oder gar nicht vorkommen kann. Wenn ein Ergebnis um genau eine Stunde daneben liegt, verdächtige die Sommerzeit, bevor du den Konverter verdächtigst.
- Werte in UTC vergleichen; eine lokale Zeitzone erst im Moment der Anzeige anwenden
- Niemals eine lokale Zeit speichern, ohne auch ihre IANA-Zone oder ihren UTC-Offset zu speichern
- Rund um eine Sommerzeitumstellung den Zeitpunkt aus UTC ableiten, nicht aus einer mehrdeutigen lokalen Zeit
Zuerst die Richtung wählen
Die meisten Timestamp-Aufgaben gehen in eine von zwei Richtungen: Epoch zu Datum oder Datum zu Epoch. Die Richtung zuerst festzulegen verhindert die häufigste Ursache für falsche Testdaten und kaputte API-Payloads — den richtigen Wert falsch herum umzuwandeln.
- Epoch zu Datum: 1700000000 einfügen und das UTC- oder lokale Datum ablesen
- Datum zu Epoch: 2026-01-01 00:00:00 UTC wählen und 1767225600 erhalten
- Bestätige, ob das Ziel Sekunden oder Millisekunden erwartet, bevor du das Ergebnis kopierst
Was vor dem Kopieren eines umgewandelten Werts zu prüfen ist
Ein Konverter kann nur so korrekt sein, wie die Eingabe eindeutig ist. Bevor du einen Timestamp in einen Test, einen Cron-Job, eine Migration oder eine API-Anfrage kopierst, bestätige die Einheit, die Zeitzone und die erwartete Präzision. Die schnellste Plausibilitätsprüfung ist das resultierende Jahr: Ein Datum nahe 1970 oder weit in der Zukunft signalisiert fast immer eine Einheiten-Verwechslung statt eines Konverterfehlers.
- Erwartet das empfangende System Sekunden oder Millisekunden?
- Ist das angezeigte Datum UTC oder lokale Zeit?
- Steht der Timestamp für einen Zeitpunkt oder ein lokales Kalenderdatum?
- Speichert die Datenbankspalte natives datetime, Unix-Sekunden oder Unix-Millisekunden?
- Liegt das Ergebnis nahe 1970 oder weit in der Zukunft, was meist eine Einheiten-Verwechslung signalisiert?
Eine Umwandlung im Code prüfen
Wenn ein umgewandelter Wert zählt — eine Migration, eine Abrechnungsgrenze, ein Cron-Zeitplan — vertraue nicht einem einzelnen Tool. Leite denselben Zeitpunkt in deiner eigenen Laufzeit erneut ab und prüfe, dass beide in UTC übereinstimmen. Jede dieser Zeilen gibt eine eindeutige ISO-8601-Zeichenkette mit Z-Suffix aus, sodass es kein lokales-Zeitzonen-Rätselraten zu vergleichen gibt.
- JavaScript: new Date(1700000000 * 1000).toISOString() // '2023-11-14T22:13:20.000Z'
- Python: datetime.fromtimestamp(1700000000, tz=timezone.utc).isoformat()
- Shell (GNU): date -u -d @1700000000 +'%Y-%m-%dT%H:%M:%SZ'
- Wenn das Tool und deine Laufzeit nicht übereinstimmen, ist die Eingabe-Einheit oder -Zeitzone verdächtig — nicht der Konverter
Praxisbeispiel: ein Zeitpunkt, drei Darstellungen
Nimm den Zeitpunkt 2026-01-01 00:00:00 UTC. Als Unix-Sekunden ist er 1767225600; als Unix-Millisekunden 1767225600000; als ISO 8601 ist er 2026-01-01T00:00:00Z. Alle drei beschreiben denselben Moment — nur Format und Einheit unterscheiden sich. Der Zeitpunkt trägt nie eine eigene Zeitzone; New York würde denselben Wert als 2025-12-31 19:00:00 anzeigen, weil der Offset zur Anzeigezeit angewendet und nicht in der Zahl gespeichert wird.
Verwandte Artikel
FAQ
- Warum landet mein umgewandeltes Datum in 1970?
- Fast immer, weil Sekunden als Millisekunden gelesen wurden. JavaScripts Date und Date.now() verwenden Millisekunden, sodass ein 10-stelliger Sekundenwert im Januar 1970 landet. Multipliziere die Sekunden zuerst mit 1000.
- Warum ist meine umgewandelte Zeit um genau eine Stunde versetzt?
- Das ist ein Zeitzonen- oder Sommerzeitfehler, kein Rechenfehler. Der Konverter hat eine andere Zeitzone angewendet, oder die lokale Zeit fiel auf eine Sommerzeitumstellung. Stelle den Konverter auf UTC, um den kanonischen Zeitpunkt zu sehen, und wende dann die gewünschte Zone an.
- Welches Epoch-Konverter-Format kopiert man am besten?
- Für Code kopiere Unix-Sekunden oder -Millisekunden, je nachdem, was die Ziel-API dokumentiert. Für Menschen kopiere ISO 8601 mit einem Z oder einem expliziten Zeitzonen-Offset, damit der Zeitpunkt eindeutig ist.
- Ist ein Epoch-Konverter dasselbe wie ein Unix-Zeit-Konverter?
- Für die meisten Entwicklersuchen ja. Epoch-Konverter, Unix-Zeit-Konverter, Unix-Timestamp-Konverter und Unix-Epoch-Rechner wandeln alle zwischen Unix-Epoch-Timestamps und lesbaren Daten um.
- Warum zeigen Epoch-Konverter unterschiedliche lokale Zeiten?
- Sie wenden unterschiedliche Zeitzonen an. Der zugrunde liegende UTC-Zeitpunkt ist identisch; nur die lokale Anzeige ändert sich. Stelle den Konverter auf UTC, um den kanonischen Wert zu vergleichen.
- Woran erkenne ich, ob meine Zahl Sekunden oder Millisekunden ist?
- Zähle die Stellen. Ein moderner 10-stelliger Wert ist Unix-Sekunden; ein 13-stelliger Wert ist Unix-Millisekunden. Wenn ein 10-stelliger Wert in JavaScript nahe 1970 landet, wurde er als Millisekunden behandelt und muss mit 1000 multipliziert werden.