[ python-Bugs-989273 ] Python-2.4.0a1 test_strptime.py fails on HP-UX11i

[SourceForge.net]

Bugs item #989273, was opened at 2004-07-12 01:41
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989273&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Brett Cannon (bcannon)
Summary: Python-2.4.0a1 test_strptime.py fails on HP-UX11i

Initial Comment:
Built Python-2.4.0a1 on HP-UX11i and test_strptime.py 
fails.

See attached file test_strptime.txt



----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-13 17:49

Message:
Logged In: YES 
user_id=357491

OK, so I screwed the patch up by using the line ``tz_name.lower() in 
("UTC", "GMT")``.  Notice how everything is in caps in the tuple but I call 
str.lower()?  Nice way to guarantee that the test is never true.

Sorry about that stupid mistake, Richard.  If you happen to still have the 
last patch applied, either just apply the new patch or fix line 283 yourself 
since it is just a single word change.  That should fix it.  At least my 
blind reasoning over what could be causing the failure was correct.

Thanks for putting up with this.

----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2004-07-13 00:27

Message:
Logged In: YES 
user_id=200117

Brett, test_strptime.py still gives an error after I applied your 
patch - see attached file strptime_err.txt

Here are the variable settings from the time module:
    accept2dyear = 1
    altzone = -3600
    daylight = 0
    timezone = 0
    tzname = ('GMT', '')



----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2004-07-12 12:33

Message:
Logged In: YES 
user_id=200117

Hi Brett,

I will test your patch when I return to work tomorrow (UK time).

FYI our HP workstations are set to GMT throughout the year.

regards,
Richard


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 12:16

Message:
Logged In: YES 
user_id=357491

Well, I thought I did.  This little test is slowly turning into my personal 
Python hell for the week.

OK, so I may have a blind fix for this (if time.tzname[0] turns out to be 
UTC or GMT; realized this was a possibility).  And if that doesn't work the 
patch 
I am attaching should give us more information on what the test is 
dealing with.

Richard, can you apply the attached patch and let me know if it fixes 
things for you?  
If not please attach another traceback to the bug report.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-12 11:55

Message:
Logged In: YES 
user_id=31435

Brett, are you sure we understand this one?  It's the same 
test failing in the same way as I reported on Python-Dev, 
*but* Richard is seeing test_strptime fail in isolation (look at 
his attachment).  The failure I saw was due to interactions 
with test___all__ and test_site too -- test_strptime did not 
fail in isolation for me, but is failing in isolation for Richard.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 11:36

Message:
Logged In: YES 
user_id=357491

Thanks for the bug report, Richard.  We have isolated why the test fails 
(the test is at fault, not the code it is testing) and should have it fixed 
within a day or so.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989273&group_id=5470