classification
Title: test_strptime failures on FC2-test
Type: Stage:
Components: Library (Lib) Versions: Python 2.4
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: anthonybaxter Nosy List: anthonybaxter, brett.cannon
Priority: normal Keywords:

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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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:28anthonybaxtercreate