Datumszeichenfolgen auf Portabilität prüfen
Füge ein Datum, einen Zeitstempel oder einen längeren Protokollauszug ein und prüfe, welche Werte JavaScript `Date`, Python und andere verbreitete Parser unterschiedlich interpretieren oder ablehnen könnten.
Die Verarbeitung erfolgt lokal in Ihrem Browser. Ihre Datei wird niemals hochgeladen.
Anleitung Tool
- Füge ein Datum oder Text mit Datumsangaben ein; der Inhalt wird lokal verarbeitet.
- Starte die Datumsanalyse.
- Prüfe markierte Werte und die betroffenen Parser.
- Nutze eine ISO-8601-Umschreibung, wenn sie eindeutig ist. Mehrdeutigkeit wird erklärt statt erraten.
Annahmen
- Erkannt werden fünf konkrete Formen: vollständiger ISO-8601-Zeitstempel mit oder ohne Offset, einfaches YYYY-MM-DD mit oder ohne führende Nullen, Bindestrichdatum mit zweistelligem Jahr und Datum mit Schrägstrichen. Natürlichsprachige Daten, Unix-Zeitstempel und andere lokale Formate liegen außerhalb des Umfangs.
- Die Reihenfolge bei Schrägstrichdaten wird nur abgeleitet, wenn eine Zahl größer als 12 ist. Sind beide Zahlen gültige Monate, wird die Mehrdeutigkeit benannt.
- Das Jahrhundert zweistelliger Jahre wird nie erraten.
Quellen und Referenzdaten
Methodik
Kandidaten werden nach ihrer Form klassifiziert und mit bekannten Unterschieden von JavaScript `Date`, Python und strikten Parsern verglichen: implizites UTC gegenüber lokaler Mitternacht für reine Datumsangaben; lokale Zeit gegenüber UTC bei Zeitstempeln ohne Offset; Jahrhundertableitung zweistelliger Jahre; und Zurückweisung nicht nullaufgefüllter Werte durch strikte Parser. Nur eindeutige ISO-8601-Umschreibungen werden vorgeschlagen.
Rechenbeispiel
Mehrdeutiges Datum mit Schrägstrichen
Eingaben: 01/02/2024
Ergebnis: Kann je nach Konvention den 2. Januar oder den 1. Februar bedeuten. Es wird keine Umschreibung geraten.
ISO-Zeichenfolge nur mit Datum
Eingaben: 2024-01-15
Ergebnis: JavaScript `new Date("2024-01-15")` behandelt sie als Mitternacht UTC; andere Umgebungen können lokale Mitternacht verwenden. Westlich von UTC kann dadurch ein anderer Kalendertag erscheinen.
Datum ohne führende Nullen
Eingaben: 2024-1-5
Ergebnis: JavaScript und Python akzeptieren es großzügig, manche strikte SQL-Datumsparser nicht. Eine sichere Umschreibung ist 2024-01-05.
Praktische Hinweise
- Zeitstempel, die Systemgrenzen überschreiten, sollten einen expliziten UTC-Offset oder `Z` enthalten.
- Erzeuge in eigenem Code keine zweistelligen Jahreszahlen; Jahrhundertregeln unterscheiden sich.
- Bevorzuge ISO 8601 für Daten, die mehrere Systeme lesen.
Häufige Fehler
- Annehmen, ein ohne Fehler geparstes Datum sei überall gleich interpretiert.
- Eine Zeichenfolge YYYY-MM-DD unabhängig von Zeitzone als denselben Zeitpunkt behandeln; das Format ist als Text eindeutig, aber Parser ergänzen fehlende Uhrzeit verschieden.
Häufige Fragen
Warum ist 01/02/2024 ein Fehler, 25/12/2024 aber nur ein Hinweis?
Bei 01/02 sind beide Zahlen mögliche Monate. Bei 25/12 kann 25 kein Monat sein und legt Tag/Monat fest. Es ist nicht ISO 8601, aber nicht mehrdeutig.
Warum wird ein zweistelliges Jahr wie 24 nicht als 2024 angenommen?
Manche Systeme deuten es als 1924, andere als 2024. Die Jahrhundertkonvention variiert.
Ist 2024-01-15 wirklich riskant?
Als gespeicherter Text ist es sicher. Der Unterschied entsteht beim Interpretieren als Zeitpunkt: JavaScript behandelt ein datumsloses ISO-Datum als UTC, viele andere Sprachen als lokale Zeit.
Warum kann `new Date('2024-01-15')` den Vortag zeigen?
ECMAScript interpretiert ein ISO-Datum ohne Uhrzeit als Mitternacht UTC. In einer Zeitzone westlich von UTC kann die lokale Darstellung noch auf den vorherigen Kalendertag fallen.
Zuletzt geprüft:
Formbasierter Scanner für fünf Muster, kein vollständiger Datumsparser. Er kann bei einer tatsächlich mehrdeutigen Zeichenfolge nicht wissen, welches Datum gemeint war und löst sie nicht durch Raten auf.
Design- und Tool-Einstellungen sowie gespeicherte und zuletzt verwendete Listen werden nur in diesem Browser gespeichert.