Will Leshner wrote:
On 8/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Adding DATE and TIMEINTERVAL types to SQLite would require an
incompatible file format change. And it would go against the
basic philosophy of SQLite.
I wonder if it might not be useful to be able to ask SQLite if a value
is a date or time. I'm assuming that at some point SQLite has to
figure out if a value in a field is a date or time, and perhaps that
logic could be exposed as an API call somehow.
You can declare it to be a date or a time or both. Sqlite lets you make
the declared type of a column anything you want it to be. It is smart
enough to maintain the underlying storage type a float.
What we do with dates is add a couple extra functions into Sqlite
(simple things like a month number) and lift the date handling logic out
of Sqlite and place it is a support library for use in applications.
The way Sqlite cleverly uses a FLOAT for a date and time type and
relates it to the theoretically correct epoch makes for an excellent
date processing system. If you need it you can add functions to resolve
not just Gregorian dates but Arabic, Hebrew, and various oriental dates.
Timestamping is made simple and efficient.
Since your application or a function can access the declared type from
Sqlite your application (or a custom function) can decide on how to
interpret the FP date/time stamp.
