[DB-SIG] Asymmetry in DB-API 2.0 types

[Andy Todd]

Harald Meland wrote:
> [M.-A. Lemburg]
> 
> 
>>The driver output values are driver dependent and there's nothing
>>much the API spec could do about this because not all databases
>>support all different kinds of data types and it is not even
>>clear for which result columns a specific data type is needed
>>or desired.
> 
> 
> Wouldn't it be possible to extend the current specification for
> e.g. DATETIME:
> 
>    DATETIME
>      This type object is used to describe date/time columns in a
>      database.
> 
> to include an API for deciphering such type objects, e.g. like this
> (we'll obviously need to work on the exact behaviour of the various
> methods, this is just an example to get the discussion started):
> 
>      Objects of type DATETIME must support the following methods:
> 
>      date()
>        Return a string on the form "YYYY-MM-DD" representing the date
>        part of the object's value.
> 
>      time()
>        Return a string on the form "HH:MM:SS" representing the time
>        part of the object's value.
> 
>      ticks()
>        Return the object's value as seconds since epoch; raises
>        ValueError if object's value is not representable as ticks.
> 
>      year
>        instance variable containing the (4-digit) year, as an integer,
>        of the object's value.
> 
>      ...
> 
> The NUMBER type could be required to expose information on
> e.g. precision in a standard way, etc.
> 
> After all, every driver has to use a *single* type for each value a
> query returns; if the value doesn't fit into one of the standard types
> mentioned in the DB-API, then the driver is of course free to use some
> other type for that.

A standard way to access date, time and datetime objects is, in my 
opinion, a good idea. Most of the drivers I use work with mxDateTime but 
that can cause issues for some people because of the license.

There is an alternative. Its only in beta at the moment, but Python 2.3 
has a datetime module in the standard library;

http://www.python.org/doc/2.3b1/lib/module-datetime.html

So if we're going to pick a standard I'd be going with that one. I don't 
know if there are any plans to back port this module to prior releases 
of Python but I wouldn't be surprised.

Regards,
Andy
-- 
--------------------------------------------------------------------------------
 From the desk of Andrew J Todd esq - http://www.halfcooked.com/