[PyGreSQL] datetime.(date|datetime|timedelta)

[Christoph Zwerschke]

Mario, here are some more considerations regarding the datetime patch:

The DB-API 2 specification says:

The *preferred* object types for the date/time objects
are those defined in the mxDateTime package.
Starting with Python 2.3, module authors can *also* use
the object types defined in the standard datetime module

The current implementation does it exactly like this.
Still, it would be nice to have an option for choosing between datetime, 
mx.DateTime and raw (string) format for return values.
For the input values (sql parameters) it does not matter, since you have 
to use the Date(), Time() and Timestamp() constructors provided by the 
pgdb module anyway, you do not input mx.DateTime objects directly.

Another thing that needs to be changed in your patch:

You invented some type objects such as TIMEINTERVAL which are not part 
of the DB-API specs. I think that is possible, but you must take care 
that all type codes (returned in the cursor.description) do also equal 
one of the  type objects defined in the specs. Currently, this was also 
wrong for MONEY which should compare equal to NUMBER.

I suggest the following names and assignments of type objects:

Postgres  | stdlib type | mx type   | type object
----------+-------------+-----------+------------
date      | date        | DateTime  | DATE
time      | time        | TimeDelta | TIME
timestamp | datetime    | DateTime  | DATETIME
interval  | timedelta   | TimeDelta | TIMEDELTA

Type objects of DATE type will also compare equal to DATETIME.

I have already added these type objects in the CVS, and fixed the issue 
with the MONEY type (these changes will do no harm). (For 
simplification, I have omitted deprecated data types and timezone 
variants above, but they are included in the module.)

I have also found an answer to the question "how to deal with datestyle 
settings different from ISO". Actually, there are only 4 different 
variants, and they can be distinguished from the date value (e.g. the 
separator is different for German style). It should be a simple thing to 
write a parser which can convert all these date styles correctly (or use 
the parser in mx.DateTime if available). The only problem is that one of 
the 4 datestyles ("SQL") has 2 subvariants ("US" and "European") which 
cannot be distinguished by looking at the value only. I suggest we 
assume "US" (default), so of the 5 different datestyles only "SQL, 
European" will not be converted correctly. I think we can live with that 
if it is clearly documented. How do you think about that?

-- Christoph