Re: problem with timezone parsing

On Mon, Feb 16, 2009 at 1:16 AM, Karsten Hilbert
<[email protected]> wrote:
>> Which is going to be a problem for dates up until 1941.  It isn't
>> clear how best to handle this: ignoring the seconds portion of the
>> offset would give you a value, but it would be the wrong value.
> Would it be possible to throw a better defined exception ?
>
> Something like:
>
>        psycopg2.ProblematicTimeZoneError('cannot handle date ... in time zone ...').
>
> which would then allow me to catch it and try to work around
> it somehow (say, allow users to configure "fallback"
> timezones and retry the query).

I had a bit of a poke at the datetime parsing code, and have updated
it to handle things slightly better.

* The typecast_parse_time() function can now parse HH:MM:SS time zones.
* The typecast_PYDATETIME_cast() methods now explicitly check for
offsets that are not a whole number of minutes and raise an exception
("time zone offset NNNN is not a whole number of minutes").
* The typecast_PYTIME_cast() method now supports times with time
zones, for completeness.
* The test suite has been updated to actually test the time zone
parsing, ensuring that the correct results are returned.  The tests
for the mxDateTime backend essentially just show that the time zone
info is dropped, since it doesn't support time zones.

The extra tests turned up a bug in the handling of offsets that aren't
a whole number of hours: offsets like "-01:15" were being treated as a
45 minute offset rather than 75 minutes.  That is also now fixed, but
ity does mean that released versions of psycopg can silently return
incorrect data if you are relying on its time zone parsing.

As mentioned before, if you want behaviour different to this I'd
suggest installing an alternative typecaster.  That would also let you
fix the busted time zone parsing for released versions of psycopg2.

James.