There have been some suggestions put foreward for worthwhile changes
to SQLite which we cannot do without breaking backwards compatibility.
We normally work very hard to avoid imcompatibilities.
But in cases where the compatibility break is very minor and likely to
have minimal impact and where the change seems especially worthy, we
will consider them.

This page accumulates proposed changes to SQLite that, while
technically not 100% backwards compatible, only present very
minor changes but offer substantial benefits.  We put the proposals
here so that they can accumulate and so we will not forget the
next time we do an incompatible release.  And, by putting the
proposals here, we provide users an opportunity to complain if
a proposed change would seriously inconvenience them in ways that
we have not anticipated.

**Support A DATE Type**

Change SQLite so that it understands a new fundamental type for
dates.  There are two spare typecodes left - this would use one.
Dates would be stored as 64-bit floating point values - the julian
day number.

The incompatibility arises from the fact that a table column
with a declared type of DATE would now undergo type coercion
whereas formerly it would.  This might lead to subtle problems
in programs that currently use columns of this type.

The DATE type would only work on new databases.  Legacy databases
would continue to exhibit the legacy behavior.  Older versions
of SQLite would not be able to read or write databases that used
the new DATE type.