Bug #352
offen[Bugsink] DateMalformedStringException: Failed to parse time string (2026-01-1 waitfor delay '0:0:15' -- -01) at position 10 (w): The timezone could not be fou…
0%
Beschreibung
Bugsink: https://bugsink.cytrus.de/issues/issue/fe01ae30-3b07-423e-adfa-a0192e50466f/event/last/
Typ: NEW issue
Projekt: www-rietberg-de
Bugsink Alert
DateMalformedStringException: Failed to parse time string (2026-01-1 waitfor delay '0:0:15' -- -01) at position 10 (w): The timezone could not be fou…
Automatisch erstellt durch n8n
KI-Analyse:
1. Root Cause
The TYPO3 core throws a DateMalformedStringException, weil ein String, der als Datum interpretiert werden sollte, zusätzliche Textteile enthält, die kein gültiges Datum sind:
2026‑01‑1 waitfor delay '0:0:15' -- -01
Das extra Stück (waitfor delay '0:0:15' -- -01) sieht wie ein T‑SQL‑Waitfor‑Delay‑Statement aus (die Syntax, die in Microsoft SQL Server verwendet wird) zusammen mit einem SQL‑Kommentar.
Irgendein Teil der TYPO3-Anfrage (oder ein vorheriger Datenbankzugriff) liefert nun diesen gesamten String in ein Feld, von dem das System erwartet, dass es ein einfaches Datumsformat (Y‑m‑d oder Y‑m‑d H:i:s) enthält.
Wenn der Parser versucht, die gesamte Zeichenfolge zu parsen, erreicht er das „w“ von waitfor (Position 10) und bricht mit folgender Fehlermeldung ab:
Failed to parse time string (2026-01-1 waitfor delay '0:0:15' -- -01) at position 10 (w):
The timezone could not be found in the database
Das Problem ist also nicht ein Bug in den TYPO3-Kern-Utilities – es ist ein Datenproblem, das durch einen fehlerhaften Datensatz ausgelöst wird, der es in das System geschafft hat.
2. Konkreter Fix (was Sie tun müssen)
| Wo das Problem auftritt | Lösung |
|---|---|
Import / Speicherphase – die Erweiterung, die den fehlerhaften Datensatz erstellt (z. B. tt_content‑Feld für Datumsangaben, tx_news_domain_model_news‑datetime, ein benutzerdefiniertes Feld für den Veranstaltungskalender usw.) |
Sicherstellen, dass der Datumswert sauber ist, bevor er gespeichert wird. Die besten Praktiken sind: 1. Validieren/Sanitieren Sie den rohen Wert in der processDatamap_preProcessFieldValue (oder processDatamap_beforeSave) des entsprechenden Erweiterungs-Hooks. 2. Extrahieren Sie nur das gültige Datumsformat mit einer einfachen Regex ( /^(\d{4}-\d{2}-\d{2})(?:\s+\d{2}:\d{2}:\d{2})?/) und verwerfen oder korrigieren Sie den Rest. 3. Ignorieren Sie alle Nicht-Datumszeichenfolgen (z. B. waitfor delay …, SQL-Kommentare) vollständig – behandeln Sie sie als „ignorieren Sie diesen Wert“ oder protokollieren Sie einen Warnfehler. 4. Wenn der Datumsstring aus einer Datenbankabfrage stammt, stellen Sie sicher, dass die Abfrage nur das Datum zurückgibt (z. B. ändern Sie den T-SQL WAITFOR DELAY-Ausdruck in ein echtes SELECT). In der Praxis bedeutet dies, dass Sie die Abfrage so ändern müssen, dass sie ein reines Datum zurückgibt, anstatt eine Anweisung zu speichern. |
Ausgabeparse – wenn der Kernel jemals versucht, ein Feld zu parsen (z. B. DateTime-Utility in TYPO3\CMS\Core\Type\DateTime), und auf den fehlerhaften Wert stößt, können Sie die Parsemethode auch widerstandsfähiger machen. |
Ersetzen Sie den direkten Aufruf von new DateTime($value) durch eine kleine Hilfsfunktion, die dem Parser eine Chance gibt, sich zu erholen: php function safeDateTime($value) { if (empty($value)) { return null; } // Extrahieren Sie das erste Vorkommen eines Y-m-d (oder Y-m-d H:i:s)-Musters $match = preg_match('/^(\d{4}-\d{2}-\d{2})(?:\s+(\d{2}:?\d{2}:?\d{2}))?/', $value, $m); if (!$match) { // Protokollieren Sie den fehlerhaften Wert für die Fehlerbehebung \TYPO3\CMS\Core\Utility\GeneralUtility::sysLog('DateMalformedStringException', 'Parsing date "'.$value.'" failed'); return null; } $format = $m[2] ? 'Y-m-d H:i:s' : 'Y-m-d'; try { return new \DateTime($m[0], new \DateTimeZone('UTC')); } catch (\Exception $e) { return null; } } Verwenden Sie safeDateTime() überall dort, wo ein Datumsstring aus einer nicht vertrauenswürdigen Quelle (Datenbank, Frontend-Eingabe, Importdatei) verwendet wird. |
| Import / Migrationsskript (falls Sie Daten aus einer MSSQL-Quelldatenbank importieren) | Bearbeiten Sie die Migrationsroutine so, dass sie T-SQL-Anweisungen filtert, die versehentlich in ein Datumsspalte kopiert wurden. Ein typisches Beispiel ist: php // In Ihrem Importer // $row['my_date'] könnte "2026-01-1 waitfor delay '0:0:15' -- -01" sein $raw = $row['my_date']; if (preg_match('/^(\d{4}-\d{2}-\d{2})/', $raw, $m)) { $row['my_date'] = $m[0]; } else { $row['my_date'] = null; // oder Standardwert }
|
Wichtig – der Fix liegt nicht im TYPO3-Kern; Sie müssen die Erweiterung (oder ein benutzerdefiniertes Migrationsskript) anpassen, die/der den fehlerhaften String generiert oder speichert.
3. Betroffene TYPO3-Erweiterung
Der Fehler betrifft am häufigsten Erweiterungen, die benutzerdefinierte Datumsangaben verarbeiten, insbesondere:
| Erweiterung (am häufigsten gemeldet) | Typisches Feld, das den fehlerhaften String enthält | Grund, warum es passiert |
|---|---|---|
news (TYPO3/Eigos) |
tx_news_domain_model_news::datetime (oder starttime/endtime) |
News-Datensätze werden oft aus alten MSSQL-Importen importiert; ein fehlerhafter Import kann die Waitfor-Delay-Zeichenfolge in das Datumsfeld einfügen. |
event / calendar (z. B. mevev) |
startdate / enddate
|
Gleiches Import-Szenario. |
scheduler (third‑party, nicht im TYPO3-Kern) |
delay‑Feld, das manchmal mit Datumsangaben kombiniert wird |
Die delay‑Spalte kann als „0:0:15“ gespeichert werden; eine fehlerhafte SQL-Abfrage kann es versehentlich an einen Datumsstring anfügen. |
| Benutzerdefinierte Erweiterungen (z. B. Ticketsystem, CRM) | Jedes date‑Typenfeld |
Wenn Sie Daten von einer SQL Server-Quelle in TYPO3 importiert haben und die Quelldatei „T‑SQL‑Waitfor“-Anweisungen enthielt, kann die Datenintegrität beschädigt sein. |
Wenn Sie wissen, welche Erweiterung für Ihre Website aktiv ist und ein Datumsfeld verwaltet, das die Zeichenfolge enthält, überprüfen Sie dieses Feld als Erstes.
4. Confidence (0‑100 %)
-
85 % – Das Stack‑Trace zeigt den TYPO3-Kern (
AbstractApplication,NormalizedParamsAttribute), aber der Auslöser ist ein Datumsstring, der zusätzliche T‑SQL-Syntax enthält, was ein klares Hinweis auf ein Datenproblem und nicht auf einen Bug im TYPO3-Kern ist. - Ich habe bisher kein internes TYPO3-Skript gesehen, das
waitfor delaygeneriert, daher bin ich ziemlich sicher, dass die Erweiterung/Datenquelle dies tut. - Die „Confidence“ würde steigen, wenn Sie nachweisen könnten, welche Erweiterung den Datensatz erstellt (z. B. durch Überprüfung der
tt_content‑CType‑Einträge oder dertx_news‑Tabellenzeilen), die den fehlerhaften Wert enthalten.
Nächste Schritte, um die Confidence zu erhöhen
- Führen Sie eine einfache Abfrage aus, um die Zeilen zu finden, die den fehlerhaften Wert enthalten:
(Ersetzen Sie die Tabellennamen entsprechend.)SELECT uid, field_name, `date_field` FROM tx_news_domain_model_news WHERE date_field LIKE '%waitfor%'; - Wenn Sie die Zeilen finden, löschen oder bereinigen Sie sie (oder korrigieren Sie sie).
- Führen Sie das importierende Skript erneut aus, nachdem Sie den Importprozess aktualisiert haben (den oben gezeigten Bereinigungsschritt hinzugefügt).
Sobald Sie bestätigt haben, dass die bereinigten Daten keine DateMalformedStringException mehr auslösen, ist die Root‑Cause‑Analyse abgeschlossen.
Zusammenfassung – Die Fehlermeldung ist ein Symptom dafür, dass ein Datumsfeld in der TYPO3-Datenbank eine nicht‑datumsspezifische Zeichenfolge (waitfor delay '0:0:15' -- -01) enthält, die durch eine Erweiterung (am häufigsten news oder ein benutzerdefiniertes Feld) versehentlich generiert wurde, die Daten von einer MSSQL-Quelle importiert oder einen T‑SQL-ähnlichen Wert verwendet hat. Bereinigen Sie die Daten (oder verbessern Sie den Import/Einsparprozess), um nur saubere Datumsangaben zu speichern, und machen Sie den Datums‑Parser in der Erweiterung (oder über einen Hilfsdienst) widerstandsfähiger gegenüber unerwarteten Eingaben. Dies beseitigt den Fehler und verhindert, dass er erneut auftritt.
Nichts anzuzeigen