Guide
Ungültiger Zeitstempel: Schnelle Diagnose und Korrekturen
Die schnelle Diagnose-Checkliste
- Überprüfen Sie die Länge: 10=Sekunden, 13=ms, 16=µs, 19=ns.
- Überprüfen Sie Ziffern: nur Zahlen; Leerzeichen/Buchstaben entfernen.
- Überprüfen Sie den Bereich: Ist das resultierende Datum plausibel und 64-Bit-sicher?
- Überprüfen Sie die Zeitzone: Konvertieren Sie zuerst in UTC und wenden Sie dann den Zielversatz an.
- Überprüfen Sie DST-Edge: Verwenden Sie bei der Lokalisierung eine IANA-Zone (
America/New_York).
Müssen Sie es jetzt verifizieren? Springen Sie zu Unix Timestamp Converter oder Batch Converter.
Häufige Fehlertypen
- Längenkonflikt: 13 Ziffern werden als Sekunden behandelt → weit in der Zukunft liegendes Datum.
- Nicht-stellige Zeichen: versteckte Leerzeichen, Kommas oder Buchstaben.
- Außerhalb des zulässigen Bereichs: 32-Bit-Sekundenüberlauf über 2038 hinaus; Negative werden in einigen Systemen nicht unterstützt.
- Zeitzonenmehrdeutigkeit: Ortszeit des Servers im Vergleich zur erwarteten UTC.
- Umstellung auf die Sommerzeit: Das Parsen in die Ortszeit während der fehlenden Stunde führt zu einem Fehler.
Validierungsschritte (Kopieren-Einfügen)
// JavaScript: validate & normalize to milliseconds
export function normalizeEpoch(raw) {
const trimmed = raw.trim();
if (!/^[0-9]+$/.test(trimmed)) throw new Error("Digits only");
const len = trimmed.length;
if (len === 10) return Number(trimmed) * 1000;
if (len === 13) return Number(trimmed);
if (len === 16) return Number(trimmed) / 1000;
if (len === 19) return Number(trimmed) / 1_000_000;
throw new Error("Invalid length");
}
# Python: validate & to datetime (UTC)
from datetime import datetime, timezone
def parse_epoch(raw: str) -> datetime:
if not raw.isdigit():
raise ValueError("Digits only")
n = len(raw)
if n == 10:
ts = int(raw)
elif n == 13:
ts = int(raw) / 1000
elif n == 16:
ts = int(raw) / 1_000_000
elif n == 19:
ts = int(raw) / 1_000_000_000
else:
raise ValueError("Invalid length")
return datetime.fromtimestamp(ts, tz=timezone.utc)
-- SQL (PostgreSQL): validate timestamp length in a table
SELECT id, ts_raw,
CASE
WHEN ts_raw ~ '^[0-9]{10}$' THEN 'seconds'
WHEN ts_raw ~ '^[0-9]{13}$' THEN 'milliseconds'
WHEN ts_raw ~ '^[0-9]{16}$' THEN 'microseconds'
WHEN ts_raw ~ '^[0-9]{19}$' THEN 'nanoseconds'
ELSE 'invalid'
END AS ts_precision
FROM events
WHERE ts_raw !~ '^[0-9]{10}$'
OR ts_raw::numeric > 32503680000; -- > 3000-01-01 as a sanity bound
Vorlagen reparieren
- Präzisionskorrektur: Länge erkennen → auf Millisekunden skalieren → Analyse erneut ausführen.
- Trimmen/Bereinigen: Leerzeichen und Kommas vor der Regex-Validierung entfernen.
- Range Guard: Werte außerhalb eines plausiblen Fensters begrenzen oder verwerfen (z. B. Jahr
< 2000oder> 2100). - Zeitzonen-Korrektur: Als UTC analysieren und dann entsprechend dem Ziel-Offset/der Zielzone des Benutzers formatieren.
- DST-sicheres Parsen: UTC bevorzugen; Wenn lokal erforderlich ist, verwenden Sie IANA-Zonenbibliotheken.
FAQ
- Was ist die sicherste Standardeinstellung? Als UTC analysieren und dann in die angeforderte Zeitzone formatieren.
- Wie verhindere ich 2038-Probleme? Als 64-Bit-Ganzzahlen speichern; Vermeiden Sie sekundenbasierten 32-Bit-Speicher.
- Wie werden Daten stapelweise bereinigt? Verwenden Sie einen Regex-Vorfilter + längenbasierte Skalierung und leiten Sie sie dann in einen Konverter weiter. Versuchen Sie Batch Timestamp Converter.