Brett C. wrote:
> Jeremy Hylton wrote:
>
>> On Thu, 2003-06-05 at 17:56, Jeremy Hylton wrote:
>>
>>> I've been running the python tests frequently today, from a checkout I
>>> did mid-morning. I just noticed an unexpected failure. This is with a
>>> regular build; I'll see if it is repeatable.
>>
>>
>>
>> It is repeatable.
>>
I pass with no issues.
>> It looks like the regex is expecting EST and getting EDT.
>>
Yep. It looks like the timezones list is getting botched.
>
> I will take a look tomorrow.
I changed my mind. =)
> Until then, Jeremy, can you see if it
> passes if you back out the recent changes that modified timezone
> handling (I think it was just the last one; added GMT and UTC
> acknowledgement as well as handilng the timezone better, or so I thought)?
So it is actually two versions ago; version 1.16 is what I would like
you to run (1.17 tried to make timzone handling more robust and 1.18
calls time.tzset in case there was a locale change since time.tzname
does not get changed without the call). Can you also run the below line
of code and paste in what gets spit out?::
>>> import time, _strptime; time.daylight; time.tzname;
_strptime.LocaleTime().timezone; time.daylight; time.tzname; time.tzset()
-Brett
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4