Re: psycopg2: parsing timestamps with odd time zones

On Wed, May 19, 2010 at 03:41:53PM +0100, Daniele Varrazzo wrote:

> > apparently, the exception thrown by Python when failing to
> > parse time zones with seconds in them has changed. It used
> > to be
> >
> >        "DataError: unable to parse time"
> >
> > but now is the more specific:
> >
> >        "ValueError: time zone offset XXXX is not a whole number of minutes"
> 
> I don't know much about this type caster: please accept a few
> questions to better understand its purpose and our limitations.

Sure.

> Is this really the best we can do? I feel depending on the exception
> message a little bit brittle.

This is surely brittle but I would *want* it to be as narrow
as possible and not mask any other problems.

> Couldn't we partially pre-parse 's' and
> pass DATETIME something stripped of the part it makes it fail, just to
> put the things back before returning?

We surely could but by that we would be truncating the truth
to the nearest minute.

> I don't know exactly the type of strings TSTZ_W_SECS expects (and the
> object it returns): it would be nice to have a few of them in the test
> suite, both for testing and documentation.

If you happen to have a locale which contains seconds within
the timezone definition you will find that Python cannot
deal with that. If this typecaster is registered those
seconds will be truncated away and the original DATETIME
typecaster is used again on that.

This makes the result wrong, though, by up to 59 seconds,
unless the seconds where "00".

> What stops us to have a default typecaster doing the right thing in
> first place?

It does, it's just that Python cannot deal with the right thing.

> Is it because TSTZ_W_SECS truncates what can't be done
> (instead of raising an exception)?

Yes.

> I think it could be accomplished by
> not relying on the python parser for the timezone part. It also seem
> that the current constructor implementation of tz.FixedOffsetTimezone
> should be changed to allow for seconds, which can be probably done
> without breaking compatibility. Apart from that, I see no reason to be
> unable to deal with seconds in the timezone (I assume pytz can deal
> with them)... am I overlooking anything?

I would surely love to see a better implementation.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346