On 12/26/06, Joe Wilson <[EMAIL PROTECTED]> wrote:
How do you propose that someone adds support for an official SQLite DATE
type in the 100 or so SQLite wrappers/drivers for various languages
and operating systems to get them all to agree on this standard DATE type?
Only by making an official SQLite DATE type in the SQLite distro
can you acheive this. What code I may write in my wrapper is irrelevant
if I try to open my database with another wrapper that I did not
write.
The truth is it's probably too late for SQLite3 to have an official
DATE type since the API is more or less frozen. Such a new type could
only be added in a hypothetical SQlite4 - which may never happen.
I give up.
no, don't. You are making very logical and sensible points. I myself
was under the impression that SQLite3 did start implementing DATETIME
type, but now you have lifted the veil from my eyes. i have an table,
a rather large table, where datetime data comes in as a text string
(y'know, yyyy-mm-dd hh:mm:ss), and I was storing it thusly, even
though I was converting it to unix seconds for doing some datetime
math. Now, I will actually store them as unix seconds to primarily
save space, make the db more efficient, and also to benefit from other
qualities of integers (sorting, for example). Converting the data to
human friendly string is trivial. Nevertheless, implementing a native
DATETIME type would be very nice. Yes, SQLite is growing in
complexity, and that is a natural growth, however, DATETIME is a very
fundamental and common data type requiring manipulation in many
applications. I certainly see its value.
Yes, I also once read DRH say that SQLite 4 would never happen, and I
wondered why such emphatic statement, esp. given the recent desire for
3.3.9 ;-). I mean, is there some legal or philosophical reason that
SQLite version would be an asymptote of 4?
--- John Stanton <[EMAIL PROTECTED]> wrote:
> If drivers and such concern you the solution is obvious, implement the
> DATE type in the driver or "wrapper". Sqlite's basic architecture makes
> it simple.
>
> The Sqlite library is correct in being light and biased towards a small
> footprint for embedded applications. Adding layers of software to
> implement extra functions, interfaces etc is no problem, it is the way
> it is intended to be used.
>
> Joe Wilson wrote:
> > 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]
-----------------------------------------------------------------------------
--
Puneet Kishor http://punkish.eidesis.org/
Nelson Inst. for Env. Studies, UW-Madison http://www.nelson.wisc.edu/
Open Source Geospatial Foundation https://edu.osgeo.org/
---------------------------------------------------------------------
collaborate, communicate, compete
=====================================================================
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
