>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
None of the numeric timestamps have an associated timezone except for the Windows OLE Timestamp, which is a localtime offset. Everyone except Microsoft is just a little bit too big to exist in only a single timezone and all other timestamps are offsets from a UTC (or GMT) base. Timezone is something that is applied and removed at the User Interface level and should never exist below the presentation level. >(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 _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
