SQLite advocacy aside, I was just addressing your original statement: Most Sqlite users know that Sqlite implements a DATE type
which is not strictly true. Me, you and most SQLite users have seperately come up with conventions to handle their particular date usage patterns. There is no disputing the value of the sqlite date functions. While conventions are fine for individual applications, sometimes policy is necessary for such things as database drivers (JDBC and ODBC being the most common). SQLite's manifest typing sometimes cause the various 3rd party drivers to represent date columns as different types and values. In one driver a DATE is represented as TEXT, another as some form of DATE. Each driver makes assumptions about how dates are handled and converted to/from test. Sometimes these assumptions are correct and sometimes they are wrong. There's no way a third-party driver can possibly know what is in the mind of an individual SQLite database designer and what intent they had for a particular date field. If SQLite supported an official DATE type, such inconsistancies could be avoided, and the underlying storage of DATEs could be consistant across all applications and could potentially be stored in a more space-efficient form in the database file, as an added bonus. --- John Stanton <[EMAIL PROTECTED]> wrote: > From my perspective Sqlite does implement a DATE type by having the > function support for an epoch based date stored in a floating point > number plus declared types. The Sqlite epoch appears to be the > theoretically correct one based on an epoch somewhere in antiquity and > compatible with all the world's significant calendars. [...] __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
