On 1/14/15, Stephan Beal <sgb...@googlemail.com> wrote: > On Wed, Jan 14, 2015 at 2:09 PM, Chris Keilitz <keil...@gmail.com> wrote: > >> Since sqlite and most RDMS implementations have functions to convert to >> and >> from both options and using a LONG should allow the date/time to function >> way past 2038, > > > In my experience, having the timestamp in Unix Epoch gives you something > which can be easily converted by a wide variety of tools, and simplifies > calculation of time deltas (provided you don't need to account for > timezones, locale-specific summer/winter time changes, and similar > absurdities). That said, for humans Unix timestamps are basically just a > pain in the butt. If your data are there for the software, as opposed to > the humans, i personally find Unix Epoch simpler to work with. If the data > are strictly for display/reading by humans, without much app logic tied to > them, ISO8601 is my preferred form (YYYY-MM-DD HH:ii:ss...). >
SQLite support "unix time" (seconds since 1970) and ISO8601 and also Julian Day number - the number of days (including fractional days) since noon in Greenwich on November 24, 4714 B.C. Use whichever format seems appropriate. Note that all three formats sort in time order. The date and time functions in SQLite will easily convert between all three formats. Please familiarize yourself with ISO8601. Consider using it yourself when communicating dates, instead of YY-MM-DD or MM/DD/YYYY or various other formats which are potentially ambiguous and which often do not sort in time order. -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
