Bevor es in ELO ISO-Datumswerte gab (wohl rund um Version 6 herum), gab es hier früher nur Text oder Datumsfelder. Allerdings ohne große Prüfung, außer man hatte hier mittels Scripting eine solche durchgesetzt. Im Zuge verbesserter Suchmöglichkeiten (bspw. ISearch) oder die Bereichssuche des IndexServers sucht man hier gerne nach Konvertierungsmöglichkeiten in das ISO-Datum Format.

Kann ein günstiger Weg sein, muss es allerdings nicht. Das hängt dann doch ein wenig von der Datenbankengine ab und der Vielfalt, die hier hinter den Feldinhalten steht. Variieren die Datumsformate kann das eher ungünstig sein, hier wählt man ggf. am Besten den Weg eines neuen Feldes, um sicher zu gehen, dass man fehlerhafte Werte ggf. erkennen und anders adressieren kann. Fehlerhafte Werte einfach so zu beibehalten, kann zu Problemen bei anderen Komponenten führen. Bspw. bei der ESearch oder anderen Programmen, die bspw. mit ISO-Datumswerten arbeiten. Beim SQL-Server kann man hier gut und gerne mit TRY_CONVERT arbeiten, bei ORACLE mit REGEXP_LIKE oder ON CONVERSION ERROR. Bei Postgres stellt sich die Frage eher nicht, weil es diese Engine noch nicht so lange gibt, als das hier noch so alte Felder vorhanden sind. Im Fall des Falles kann man hier einfach ChatGPT oder ähnlich fragen.

ISO-Datum in natives Datum:

SELECT CASE
         WHEN REGEXP_LIKE(your_column, '^\d{8}$')
         THEN TO_DATE(your_column, 'YYYYMMDD')
         ELSE NULL
       END AS converted_date
FROM your_table;

Deutsches Datum in natives Datum:

SELECT CASE
         WHEN REGEXP_LIKE(your_column, '^\d{2}\.\d{2}\.\d{4}$')
         THEN TO_DATE(your_column, 'DD.MM.YYYY')
         ELSE NULL
       END AS converted_date
FROM your_table;

Wenn man sich hier wirklich an die Datenbank wagt, dann sollte man hier nicht vergessen den objtstamp zu aktualisieren. Ansonsten greift die ESearch das Objekt nicht mehr auf. Man kann alternativ aber auch eine komplette Neuindizierung starten, diese kann aber je nach Archivgröße auch dem entsprechend Zeit in Anspruch nehmen.