> This is probably what we will need to do, but since the failing tests
> were bogus to begin with it may be a case of incremental
> improvement. This is definitely a problem, though, that we should
> resolve one way or another.
> It's also worth noting that the i18n code currently relies on the
> localization database for much of their timezone information AFAIK.
> The error could be there too, even though it was Stuart's checkin
> that triggered this failure in a bogus test. Dunno. Sigh.
Well, src/pytz/zoneinfo/EST.py contains the "minus 5 hours and 20
minutes" (-19200 seconds) offset the test is actually returning:
_utc_transition_times = [
_transition_info = [
I don't know how to read this data. A zone named "CMT" doesn't make
sense to me in a file named EST.py. -18000 is the correct offset for
current EST rules, and don't know either why it's apparently using the
-19200 thingie instead.
Zope3-dev mailing list