And with SQLite you're stuck with what to use: Do it correctly, and use REAL, INTEGER or TEXT for Date(Time), and remember it in the Frontend-Code,
or do it wrong using DATETIME as DataType for the Column during creation, so it gets written into the DDL-Metadata, and HOPE SQLite never changes this.
Due to the exceptionality of SQLite in terms of dynamic typing (they state that they are the only RDBMS with that feature), my feeling is that we should not enforce field/param data type inside the object itself (field/param in this case).
It should be something like
if I have a value with some storage class, I try to represent to the caller according to how the caller asks for.
In this way if value is REAL and I call AsFloat I will get a float, AsDateTime gives datetime.
Similarly if I have a TEXT, AsDateTime gives datetime tring to interpret the TEXT. Or a string if I ask for AsString on that record.
I don't know if this appears senseful, but I see few possibilities of relying on SQLite DDL information, as sometimes it is also possible to define columns with no type at all (
https://www.sqlite.org/syntax/column-def.html - it is possible to bypass the type-name).
Moreover, with this dynamic model, I believe is very possible to have, for the same column, different storage types in different rows, so for sure an approach based on the datatype fixed inside the TField object has few chances to work.