[Gary Poster]
> 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
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to