[DB-SIG] date/time handling

[David Rushby]

--- Christoph Zwerschke <cito at online.de> wrote:
> I don't like the idea that the admin can break or 
> change applications (he might not even be aware of) simply
> by installing the mx.base package.

I strongly agree with this.  Implicitly changing the representation of
certain types of data on the basis of what packages happen to be
installed on the system is insane.

Consider the act of transferring a Python database app between Linux
distributions.  If one distribution doesn't include mx in its default
set of packages, but the other does, the app's behavior would change
without any indication from the sysadmin that such a change is desired.

> What we really need is a way for DB-API apps to explicitely
> declare what datetime module shall be used.

Some database modules already have a system of input and output
conversion callbacks that applies to all types, not just dates, times,
and timestamps.  One example is KInterbasDB:
 
http://kinterbasdb.sourceforge.net/dist_docs/usage.html#adv_param_conv_dynamic_type_translation

I would be disappointed to see the DB API standard revised to specify a
mechanism for date/time/timestamp representation selection, but fall
short of generality.  That would seem to me like a wasted opportunity.

On the other hand, there are enough engine-specific differences in
relational database type systems that creating a fully general standard
might be impossible (or so ugly as to be unusable).

Consider the unusual extensibility of the PostreSQL type system,
SQLite's weaker-than-normal typing, and debatable points such as the
handling of textual blob data (suck it into a string in memory or
present it as a stream?).  I fear that a standard that tried to address
all of those issues for all database engines would be a monstrosity.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com