[Zope3-dev] Failing test, Zope3 trunk, Windows

[Fred Drake]

On 9/6/05, Tim Peters <tim.peters at gmail.com> 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:
> 
>     def testParseTimeZoneNames(self):
>         dt = self.format.parse('01.01.2003 09:48 EST', 'dd.MM.yyyy HH:mm zzz')
>         self.assertEqual(dt.tzinfo.utcoffset(dt), datetime.timedelta(hours=-6))
> 
> 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
> either ;-)

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? 
Not sure.

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 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
simultaneously.)


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
Zope Corporation