> One problem with having an actual internal date format is how to dump it into > a text file or to a text interface. You end up turning it into a number or a > string anyway, so you might was well store it that way.
The problem not having a DATETIME field is, however, very simple: When reading a foreign database which stores date values as a number, I have to guess on how to get back the correct date. People and companies are very creative in that regard: Is it unix-based? Is it like Excel? Is it days, minutes, seconds, or even milliseconds? Since when? Compatibility shouldn't be affected imho. You can always continue to use INTEGER or FLOAT, and databases using INTEGER or FLOAT continue to be fully compatible. But newly created databases could store date values in a properly defined way that is readable for others as well. Import and export from/to text formats shouldn't be a problem either as other DBSs already support DATETIME and TIMESTAMP and obviously have found a representation of such values in SQL (it's probably defined in the SQL standard anyway). _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
