[DB-SIG] date/time handling

M.-A. Lemburg mal at egenix.com
Thu Aug 3 11:36:32 CEST 2006


Christoph Zwerschke wrote:
> Hello all,
> 
> trying to improve date/time handling in PyGreSQL we stumbled over the 
> following questions:
> 
> 1) Should mx.DateTime still be preferred over stdlib datetime (if both 
> are available)? Or should we handle it the other way around meanwhile?

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 ?

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.

This is the reason why mxODBC tries to support all of them and
leads up to the next question...

> 2) We want to provide a possibility to explicitly choose the preferred 
> date/time type, i.e. mx.DateTime or stdlib datetime or even Ticks or 
> Python tuples, or strings.
> 
> The mx.odbc module does this via an attribute "datetimeformat" of the 
> connection object that can be set to constant values named 
> DATETIME_DATETIMEFORMAT or STRING_DATETIMEFORMAT (unfortunately, the 
> former means mx.DateTime in this context, and there is no value defined 
> for stdlib datetime).

It's not an ideal approach. At the time I just needed some
way to configure the format.

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.

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).

> Do you think this is a good idea? Maybe we can agree on a preliminary 
> standard that can be proposed for a future DB-API 3 (btw, is there any 
> work in progress to create such a new version)?

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

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 03 2006)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::


More information about the DB-SIG mailing list