Re: psycopg2: parsing timestamps with odd time zones

Hello Daniele,

thanks for your detailed analysis.

Personally, I agree with making psycopg2 do the rounding by
default.

> 3. at a certain point, her program deals with an exotic input, such as
> the 1930 India trains time table.

Maybe not quite so exotic after all: GNUmed is an Electronic
Medical Record that's used worldwide. Just enter a patient
born around 1900 over there in India...

> So: why don't we do the error in first place, by rounding to the
> nearest minute in typecast_PYDATETIME_cast,

Well, as you say below this would introduce a *silent* error
and that's why I too great pains to make the application of
the custom typecaster so extremely narrow.

> instead of in testing? I'd like to do the best thing, but if pytz
> doesn't use seconds in the tz either, I guess we can't do more. We
> could round instead of truncate, so the error would be +/- 30 secs
> instead of 60 and we'd be consistent with pytz.

Makes sense.

> So, I'm generally against introducing silent errors, but:
> 
> 1. because Python can't do better, and this is acknowledged by the
> best Python tz library around, and
> 2. because the current solution is to introduce the error anyway, just
> *after* the user has been bitten by the exception at least once,
> possibly in an inappropriate moment,

+1

> I am for fixing typecast_PYDATETIME_cast() to round the tz to the
> minute in first place and make register_tstz_w_secs() a no-op
> function.

+1

> If this suggestion is rejected, I propose to raise a ValueError
> subclass (e.g. TzWithSecondsError) so that TSTZ_W_SECS could deal with
> it without having to parse the error message. Because we raise the
> exception after having parsed the timestamp, we could store the
> seconds off in the exceptions, so that TSTZ_W_SECS wouldn't need
> re-parsing and could easily round the tz to the the nearest minute.

That's a great idea as well :-)

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