➜
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2004-07-12 08:41 by rptownsend, last changed 2022-04-11 14:56 by admin. This issue is now closed.
| Files | ||||
|---|---|---|---|---|
| File name | Uploaded | Description | Edit | |
| test_strptime.txt | rptownsend, 2004-07-12 08:41 | |||
| bad_timezone_strptime.diff | brett.cannon, 2004-07-12 19:16 | Blind fix for when time.tzname[0] is UTC or GMT | ||
| strptime_err.txt | rptownsend, 2004-07-13 07:27 | |||
| test_strptime_use_upper.diff | brett.cannon, 2004-07-14 00:49 | Patch for bad_timezone_strptime.diff to use str.upper() | ||
| Messages (8) | |||
|---|---|---|---|
| msg21513 - (view) | Author: Richard Townsend (rptownsend) | Date: 2004-07-12 08:41 | |
Built Python-2.4.0a1 on HP-UX11i and test_strptime.py fails. See attached file test_strptime.txt |
|||
| msg21514 - (view) | Author: Brett Cannon (brett.cannon) *  |
Date: 2004-07-12 18:36 | |
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. |
|||
| msg21515 - (view) | Author: Tim Peters (tim.peters) * |
Date: 2004-07-12 18:55 | |
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. |
|||
| msg21516 - (view) | Author: Brett Cannon (brett.cannon) * |
Date: 2004-07-12 19:16 | |
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. |
|||
| msg21517 - (view) | Author: Richard Townsend (rptownsend) | Date: 2004-07-12 19:33 | |
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 |
|||
| msg21518 - (view) | Author: Richard Townsend (rptownsend) | Date: 2004-07-13 07:27 | |
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', '')
|
|||
| msg21519 - (view) | Author: Brett Cannon (brett.cannon) * |
Date: 2004-07-14 00:49 | |
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.
|
|||
| msg21520 - (view) | Author: Richard Townsend (rptownsend) | Date: 2004-07-14 07:18 | |
Logged In: YES user_id=200117 I made the change and the test now runs without errors. Thanks for fixing this - I'm glad I could help with the testing. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:56:05 | admin | set | github: 40545 |
| 2004-07-12 08:41:05 | rptownsend | create | |