On 2/6/19 7:55 PM, Ben Asher wrote:
Hi there! We're having a debate at my company about date storage in SQLite.
SQLite has builtin support for ISO8601 in its date functions, so some folks
have started storing dates as ISO8601 SQLite-compatible date strings. Are
there pitfalls to storing dates this way compared to a unix timestamp? I'm
curious to know if anyone has experience and would highly recommend
sticking to one or the other for a particular reason. I'd also be grateful
if anyone could point me to any articles exploring this subject.
Thanks!
Ben
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Isn't ISO 8601 designed for communications with humans in an
international and standard way? It is not for storage of data.
At least in my opinion one needs a data element that one may store
and later fetch and then perform computation and comparisons with.
That would be the unix timestamp way of things. The ISO 8601 format
is for display to human beings and other soft squishy creatures. I
don't see how you can check two dates readily unless you have a pile
of libs in your pocket that do that.
So .. this works real well :
l$ date -u ; tn; sleep 4; date -u; tn -f
Wed Feb 6 20:40:54 UTC 2019
1549485654
Wed Feb 6 20:40:58 UTC 2019
1549485658.659547276
l$
Easy to compare those unix timestamps ripped out of an struct timespec.
Dennis
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
