On Wed, Jan 14, 2015 at 3: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, it seems it comes down to how many bytes it takes to store > the timestamp and how fast are the conversion routines. The application I'm > writing won't push any performance boundaries and likely won't need to > overly worry about storage. > Just for the reference, to answer your size/performance question: The timestamp will take 4 bytes of data (excluding headers etc.) per entry (until 2038, after which it will be 6). The text version will be the length of the string (20 bytes for ISO8601 with second precision). Naturally, things like comparing and sorting will be faster with the timestamp then the text version (there is just less data to compare). Of course, this is just at the theoretical level. As yo said, your app probably wouldn't need to worry about this. -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
