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

[Marcos Sánchez Provencio]

¿What is the problem with the license? I believe it is more or less the 
same as Python's. I want to thank Mr Lemburg for this and other 
contributions he has given to the Python community.

Andy Todd escribió:
> 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