On 02/04/2012 5:20 AM, Simon Slavin wrote:
On 1 Apr 2012, at 6:59am, John McMahon<j...@jspect.fastmail.fm> wrote:
Thanks Igor (and Simon)
That is pretty much the path I was thinking of taking (or possibly externally
as I import the data), was just wondering if I had missed something in the date
functions.
You're welcome. Since you haven't imported the data yet you might want to
consider how you want to store your dates. If you intend to do lots of
selecting and sorting by dates, '2012-03-30' is just a little bit slower than
'20120330' for sorting. Hardly anything in it. However, if you intend to do
lots of date calculations like the number of days between two dates, then
storing the date in the '2012-03-30' format which SQLite understands is
superior. Or you might even store dates as epoch or julian date. I've even
seen tables that store datestamps in two formats.
Hi Simon,
I have at different times and applications used all those formats. At
this time I am importing from a .dBf (client main frame dump) combining
some other details and re-exporting as a .dBf because that is what the
final application (outside my control) uses. The dates are a new
addition to the data dump. I was hoping the SQLite Date functions would
handle that format, but in the end a fairly trivial reg exp did the trick.
I find it amusing that over a hundred years after the first computer
(Programmable machine. Hollerith. Bite me.) we still haven't decided on the
best way to store dates.
Likewise.
John
--
Regards
John McMahon
li...@jspect.fastmail.fm
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
