[DB-SIG] date/time handling

[Christoph Zwerschke]

M.-A. Lemburg wrote:
 > Module authors are free to choose and support whatever date/time
 > package they feel fits the job. The DB API has historically
 > preferred mxDateTime as it was the only package available to
 > handle date/time. Nowadays, Python's builtin datetime package
 > is available for interface purposes as well.
 >
 > Supporting both certainly isn't all that hard, so why not go
 > for that setup ?

Yes, of course I will continue to support both, but now prefer stdlib 
datetime if available (before, I did it the other way around).

 > Furthermore, there are applications that don't need or require
 > any special date/time packages. Those would much rather see
 > the data stored as ticks or tuples.

Exactly. You may also want to use the raw string format as delivered by 
the database. Actually PyGreSQL did this until now, it used datetime 
types only for input. One reason was that PostgreSQL returns the date in 
a format (DMY, MDY etc.) depending on a parameter setting that you would 
need to monitor otherwise.

 > What we need for DB API 3 is a way to let the user configure the
 > type mapping in a more generic way and for both the input and
 > output types.

Concerning input format:

Since DB-API 2 defines constructors for Date, Time, Timestamp, the input 
format should be actually transparent and irrelevant to the user if you 
use these constructors, right? So no real need to define it.

Conversely, if the user defines the date/time input format, he can 
simply use the probably more versatile constructors of the respective 
format, and the DB-API does not need to define date/time constructors.

So maybe DB-API 3 should provide a possibility to choose an input type 
(default: stdlib datetime), and get rid of the date/time constructors 
(default: use the constructors in the stdlib datetime module).

 > Furthermore, you will want to be able to setup this mapping
 > per connection and cursor (with cursors inheriting
 > the setting from the connection and the connection).

That would be flexible. Should this become an attribute/property of the 
connection/cursor or should it be a keyword argument of the constructor?

 > There have been a few attempts at it, but nothing has come out
 > of those yet.
 >
 > I would like to work on a new version in the coming months.
 > My main aim is to:
 >
 > * turn some of the optional extensions we already have in
 >   the DB API 2 into standard APIs and
 >
 > * as new feature, add some way to do the type mapping

That would be great. Thanks for your engagement in all of this.

-- Christoph