As with most things, "it depends on what you're using it for." Anything where you're gonna be looking at the raw data (using the CLI or whatever) benefits from human readable format. Any slowdown of your computer parsing a timestring instead of a single number is nothing compared to the slowdown of a human trying to parse a single number instead of a timestring.
-----Original Message----- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Jens Alfke Sent: Thursday, August 24, 2017 8:19 PM To: SQLite mailing list Subject: Re: [sqlite] Date time functions not working 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 _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
