> SQLite doesn't have a DATE type. You can store dates in a SQLite > database as text, or integers or floating point numbers (e.g. "20180602", > a number of days, a number of seconds). But when you ask for a value, > that's what you'll get back. Any interpretation of that value as a > date is up to you or your software.
> Simon. That is the real crux of the situation, I have a handle on how to display DATEs whether they are NUMERIC or TEXT. Users really gather no meaning from temporal values as numbers. The real issue I suppose after some thought is the export/import of a DATE, TIME, TIMESTAMP. Most Databases for both SQL, INSERT example, and CSV is done with TEXT. Example being standard SQL DATE, YYYY-MM-DD. I think that the case is to preserve the users data in the type they have chosen for SQL export, have to test each entry for NUMERIC or TEXT. The import of the SQL INSERT statements will return the database entries to the same data. I have no control on those since they are passed directly to SQLite. CSV export will be TEXT, since that is the most likely way a spreadsheet will recognize the data. I will have to test probably import of CSV for NUMERIC or TEXT and not just assume TEXT. A determination can be made of the typeof() for the DATE field as NUMERIC or TEXT then transition the data accordingly if need be. danap. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
