On Wednesday, 8 Mar 2017 3:40 PM -0500, Paul Sanderson wrote:
> The vast majority of dates I see in SQLite databases are unix epoch integer
^^^^^
> times (seconds since 1/1/1980) with unix milli seconds a close second.
^^^^^
> Efficient to store, sort and do date arithmetic on but need to be converted
> to display.
>
> I also see unix nano seconds, 100 nano seconds, windows filetimes, chrome
> dates and NSDates/MacAbsolute very regularly.
I don't know a about "chrome dates" or "NSDates/MacAbsolute", but the
others are *time* formats, not dates. Sure, one can use a time format
to represent a date (presumably by using midnight to represent the
date), but then you should probably add a constraint to database
allowing only multiples of 86400 seconds in the field.
Perhaps this may seem a bit of a quibble, but dates are a conceptually
distinct from timestamps.
> Interestingly I rarely see dates stored in ISO8601 format/text
I don't know about that - I certainly do.
> Paul
> www.sandersonforensics.com
> skype: r3scue193
> twitter: @sandersonforens
> Tel +44 (0)1326 572786
> http://sandersonforensics.com/forum/content.php?195-SQLite-Forensic-Toolkit
> -Forensic Toolkit for SQLite
> email from a work address for a fully functional demo licence
>
> On 8 March 2017 at 20:17, David Raymond <david.raym...@tomtom.com> wrote:
>
>> Correct. The ISO strings are the de-facto standard since that's what all
>> the date and time functions take in.
>> http://www.sqlite.org/lang_datefunc.html
>>
>> "The strftime() routine returns the date formatted according to the format
>> string specified as the first argument."
--
Will
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
