Issue897817
Created on 2004-02-16 05:52 by anthonybaxter, last changed 2004-03-07 23:26 by brett.cannon. This issue is now closed.
| Messages (5) | |||
|---|---|---|---|
| msg19996 - (view) | Author: Anthony Baxter (anthonybaxter) | Date: 2004-02-16 05:52 | |
I'm seeing test_strptime failures on this box, running a version of Fedora Core that's between 1 and the new test release. test test_strptime failed -- Traceback (most recent call last): File "Lib/test/test_strptime.py", line 258, in test_timezone self.failUnlessEqual(strp_output.tm_isdst, 0) AssertionError: -1 != 0 Note that the following line (which tests GMT) also fails with a -1. The underlying failure: >>> import _strptime >>> strp_output = _strptime.strptime("UTC", "%Z") >>> strp_output.tm_isdst -1 >>> strp_output = _strptime.strptime("GMT", "%Z") >>> strp_output.tm_isdst -1 |
|||
| msg19997 - (view) | Author: Brett Cannon (brett.cannon) * ![]() |
Date: 2004-02-17 21:39 | |
Logged In: YES user_id=357491 Anthony, can you let me know what the following commands spit out?:: import time; import _strptime time.tzname time.daylight _strptime.LocaleTime().timezone _strptime.TimeRE()['Z'] That should be enough info for me to debug this. |
|||
| msg19998 - (view) | Author: Anthony Baxter (anthonybaxter) | Date: 2004-02-24 03:05 | |
Logged In: YES user_id=29957 Very very strange. I rebuilt python, and the problem has gone away. I will assign this to myself and try and reproduce it. |
|||
| msg19999 - (view) | Author: Brett Cannon (brett.cannon) * ![]() |
Date: 2004-02-24 04:26 | |
Logged In: YES
user_id=357491
A possible cause for this, Anthony, is having the timezone set to ("UTC",
"GMT") and time.daylight to a 1. This would lead to not passing the test
since there is an explicit test in the strptime code for when duplicate
non-DST and DST timezones are the same and this would do it since UTC
and GMT are injected into the non-DST timezone list for comparisons.
The default is -1 since you can't tell the proper value if both non-DST and
DST are the same. And UTC and GMT should not be considered DST
timezones obviously.
Anyway, I hope you don't find anything wrong and it was just a weird
glitch in the date settings.
|
|||
| msg20000 - (view) | Author: Brett Cannon (brett.cannon) * ![]() |
Date: 2004-03-07 23:26 | |
Logged In: YES user_id=357491 Fixed in rev. 1.31 . Basically tweaked the test that checks if time.tzname[0] == time.tzname[1] (which is bad since then you can't tell when DST is in effect or not) to take into acct. if time.tzname[1] (the DST timezone) is set to UTC or GMT. Since there is no adjustment, then just set let be set to 0 through the normal algorithm. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2004-02-16 05:52:28 | anthonybaxter | create | |
