On Solaris 8, SPARC, python-2.3

$ TZ=Australia/Tasmania 

$ python -c "import time;print time.tzname"
('EST', 'EST')

$ python Lib/test/test_strptime.py
...
FAIL: test_timezone (__main__.StrptimeTests)
---------------------------------
Traceback (most recent call last):
  File "Lib/test/test_strptime.py", line 315, in
test_timezone
    "LocaleTime().timezone has duplicate values and "
  File ".../lib/python2.3/unittest.py", line 268, in
failUnless
    if not expr: raise self.failureException, msg
AssertionError: LocaleTime().timezone has duplicate
values and time.daylight but timezone value not set to
-1
------------------------------------

Note that the test passes with TZ=US/Central,
and that Tasmania is currently on daylight savings
time. 
See also bug 763047: test_strptime fails on Linux

Logged In: YES 
user_id=357491

John, what is time.daylight set to?

Logged In: YES 
user_id=357491

OK, I think I found the problem in the code.  I have a patch here 
that fixes the bug in strptime and adds a test for it.  Can you try it 
out and let me know if the test now passes?

Logged In: YES 
user_id=838692

The system does support DST; time.daylight = 1

With the patch bad_tz_fix.diff applied get:
$ ./python Lib/test/test_strptime.py
...
ERROR: test_bad_timezone (__main__.StrptimeTests)
--------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_strptime.py", line 337, in
test_bad_timezone
    _strptime._regex_cache.clear()
AttributeError: 'module' object has no attribute
'_regex_cache'

=======================================
FAIL: test_timezone (__main__.StrptimeTests)
----------------------------------
Traceback (most recent call last):
  File "Lib/test/test_strptime.py", line 302, in
test_timezone
    self.failUnlessEqual(strp_output.tm_isdst, 0)
  File ".../Lib/unittest.py", line 292, in failUnlessEqual
    raise self.failureException, \
AssertionError: -1 != 0
--------------------------------------

But:
  $ python -c 'import time;import _strptime; print
_strptime.strptime(time.strftime("%Z"), "%Z")'
  (1900, 1, 1, 0, 0, 0, 0, 1, -1)
suggests that strptime is fixed

Logged In: YES 
user_id=357491

I know the cause of the first error is the patch is against CVS and 
not Python 2.3; I adding a caching feature to up performance since 
2.3 was released.  If you could try the patch against a CVS 
checkout of the release23-maint branch that would be wonderful.  
If not don't sweat it.

As for the last one, I will take a look.  But yes, it looks like it is 
okay now from your informal test.

Logged In: YES 
user_id=357491

OK, I found out the problem with the second failure; it was the 
order of the elif statements in strptime.  I have reordered 
them.

I have created a new diff (bad_tz_fix2.diff) that not only has the 
correction but also contains all the patches in the 2.3.1 line so it 
will bring it up to date with CVS as well as with the proposed 
patch.  If you can give this a shot, John, that would be great.

Logged In: YES 
user_id=838692

I applied the patch bad_tz_fix2.diff to the python-2.3
release.
test_strptime now passes without any problems.

Logged In: YES 
user_id=357491

Great to hear, John!  Thanks for you help.  Closing this bug as 
fixed (in both the 2.4 tree and in 2.3.x).