It's more efficient to store timestamps as numbers (e.g. the standard Unix time_t, or some other "number of seconds since a specific epoch" value, as all platforms have.) Parsing date/time strings is surprisingly expensive compared to just reading and writing numeric values. And as you've seen, there are a lot of frustrations involved in working with these strings.
The only drawbacks of numeric timestamps are that (a) they don't directly store a timezone (you have to add that as another column), and (b) they don't make it easy to do calendar operations like getting the month or year (but for I18N purposes you don't want to hardcode Western calendars into your code anyway.) —Jens _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
