On Sep 6, 2005, at 3:39 PM, Fred Drake wrote:
On 9/6/05, Tim Peters <[EMAIL PROTECTED]> wrote:
Not sure when this started to fail -- "recently":
The `pytz` was recently updated to use a newer version of the Olson
timezone database. This failure appears to be fallout from that.
Not sure what the test case is testing either:
dt = self.format.parse('01.01.2003 09:48 EST', 'dd.MM.yyyy
EST is 5 hours west of UTC, so I'm not sure why -6 would be expected.
The minus 5 hours and 20 minutes it's getting back doesn't seem right
The test also expects this to show up as the CST timezone, so I think
the test is completely bogus. Perhaps it got hacked up to make it
pass with some other version of the timezone database at some point?
Stuart Bishop: Can you look at this and determine the best way to
deal with this problem? Otherwise, we'll need to revert the pytz
update for now.
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.
This also brings up a question: How should we deal with timezones for
historic dates? The specific set of rules that apply to a given date
or datetime value have to be determined based on both the date and the
timezone indicator (abbreviation or name), applying the new US rules
for dates in the past is wrong. Is pytz prepared for this, or do we
need to figure out how we want to deal with it still? (I do hope all
the relevant information is in the timezone database, or we'll have to
think about supporting multiple versions of the database
I can answer part of this, at least. The Olson database has *very*
detailed about when to apply what time zone, and a cursory glance at
it seems to indicate that the particular new change is right. I also
know pytz works hard to reconcile the very rich Olson data with the
datetime approach (see Stuart's email http://mail.zope.org/pipermail/
This may be a bit complicated. I hope Stuart--or Stephan--can shed
some light on the problem.
Zope3-dev mailing list