@woko the best approach will depend on a a couple of things:

1. are the names of your date attributes pretty consistent across you geopackages - i.e. createdby, updatedate, etc. or do the names vary unpredictably?
2. are the geopackage date attributes an datetime data type, or are they just represented as strings/text?

If both 1 & 2 are true, then AttributeValidator is probably a good tool - Validation Rule Type = datatime etc.

If only 2 is true, then you could possibly use the schema reader to get a list of your data attributes and the find the ones that have a datetime data time

What kind of flaws in the Date field are you expecting to find? If you're trying to standardize the date fields across multiple features, you may be able to use DateTimeConverter to meet that end.

@markatsafe Thanks for the reply.

1. (semi)true: The names are diverse accept all have 'date' somewhere in the name.
2. The date attributes are strings. I will transform them to datetime.

Flaws that I expect t see are:

1. The occasional letter in the value (1978-05-22Z) and
2. All dates should be after 1950.

@woko If your date names vary - but always include 'date' in the name and your dates are strings and you're looking for patterns then I think I'd be tempted to write a little python script for PythonCaller and process your date attributes there.

@markatsafe, I am not skilled at python, so I used at the AttributeExploder and it looked very promising, but I encounter the same problem as boubcher (attribute-exploder-and-agreggator).

I am not able to recreate my tables without appointing the individual attributes in the AttributeCreator. Do you have a trick for this?