There is no DATE/TIME type is SQLite3. You can store an INTEGER epoch date/time in an INTEGER field, and INTEGER or REAL epoch date/time in a REAL field, and a TEXT format ISO-8601 subset datetime in a TEXT field. A STRICT table merely requires that the datatype be an actual supported datatype, and changes the semantics of the "value container" from being the "cell" or "value" itself to encompassing the entire column and also making the PRIMARY KEY definition, if it is not an INTEGER PRIMARY KEY of a rowid-table, be a PRIMARY KEY constraint (cannot contain nulls) rather than merely syntactic sugar for a UNIQUE constraint. This makes a table declared as STRICT follow the standard. It does not make SQLite3 **more restrictive** than the standard, it merely brings the table **up to standard**. The other "missing" stuff can already be activated by setting the DQS, TRUSTED_SCHEMA and FOREIGN_KEYs defines when building the library. Of course, it has always been possible to coerce SQLite3 to operate in strict compliance with the standard if one wanted to do so. Adding the STRICT keyword to the table definition is sufficient. If you wish to activate other features (DQS, Foreign Keys, Recursive Triggers, etc) you do that the same way you always have.