[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 = [ d(1,1,1,0,0,0), d(1908,4,22,5,19,36), ] _transition_info = [ i(-19200,0,'CMT'), i(-18000,0,'EST'), 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 Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com