www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/801900af-4c81-4cd5-9354-5b4de5170f63/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

DateMalformedStringException: Failed to parse time string ((select 198766*667891 from DUAL)-01-01) at position 0 ((): The timezone could not be found…

Automatisch erstellt durch n8n

KI-Analyse:

Analyse¶

1. Root Cause¶

Ein SQL-Ausdruck (select 198766*667891 from DUAL)-01-01 wird direkt als String an PHP's DateTime-Konstruktor übergeben, statt zuerst als SQL-Abfrage ausgeführt zu werden.

Der Ablauf:

• Irgendwo im Code wird ein Datum berechnet, indem ein SQL-Query-Building-String konkatentiert wird
• Das Ergebnis (select 198766*667891 from DUAL)-01-01 landet als roher String bei new DateTime(...) oder strtotime()
• PHP versucht, diesen String als Datum zu parsen → schlägt fehl → DateMalformedStringException
• Der sekundäre Hinweis "timezone could not be found in the database" deutet darauf hin, dass die MySQL-Zeitonen-Tabellen nicht geladen sind (mysql_tzinfo_to_sql nicht ausgeführt)

2. Fix (konkret)¶

Sofort:

// FALSCH - SQL-String wird direkt geparst
$date = new DateTime($sqlExpression . '-01-01');

// RICHTIG - Query ausführen, Ergebnis verwenden
$result = $connection->executeQuery('SELECT 198766*667891 FROM DUAL')->fetchOne();
$date = new DateTime($result . '-01-01');

Zusätzlich MySQL-Zeitzone fixen:

mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql

Dann SELECT @@global.time_zone; prüfen – sollte nicht SYSTEM zurückgeben falls TZ-Tabellen fehlen.

Langfristig: Den Code-Review des betroffenen UserFuncs/Hooks prüfen – niemals SQL-Ausdrücke als Datum-String verwenden.

3. Betroffene Extension¶

Nicht eindeutig identifizierbar aus dem Stacktrace – die wichtigsten Frames (Application-Code) fehlen. Die Stacks zeigen nur den TYPO3-Core-Middleware-Stack. Der tatsächliche Bug liegt im Application-Code (vermutlich ein custom UserFunc, Hook oder eine Extension, die Datumsberechnungen über SQL macht).

Häufige Kandidaten: sf_event_mgt, news, calendar_base, oder eine Custom-Extension mit TypoScript-UserFuncs.

4. Confidence¶

• Root Cause Analyse: 85% – Die Fehlermeldung ist eindeutig: SQL-String wird als Datum geparst.
• Betroffene Extension: 30% – Ohne den eigentlichen Application-Stack nicht identifizierbar.
• Fix-Richtung: 95% – SQL ausführen statt String parsen ist korrekt.

Empfohlene nächste Schritte¶

1. Full-Stacktrace ohne /vendor/-Filter anfordern
2. In der eigenen Extension/Custom-Code nach DUAL, DateTime und SQL-Konkatenation suchen
3. grep -r "DUAL" config/ ext/ im Projekt ausführen