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

[Gary Poster]

On Sep 6, 2005, at 3:39 PM, Fred Drake wrote:

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

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/ 
zope3-dev/2005-August/015222.html).

This may be a bit complicated.  I hope Stuart--or Stephan--can shed  
some light on the problem.

Gary