=== ERROR MASSAGE ===

$ make test
...
test test_time failed -- Traceback (most recent call last):
  File "/vol/tmp/Python-2.3b2/Lib/test/test_time.py",
line 107, in test_tzset
    self.failUnless(time.tzname[1] == 'AEDT',
str(time.tzname[1]))
  File "/vol/tmp/Python-2.3b2/Lib/unittest.py", line
268, in failUnless
    if not expr: raise self.failureException, msg
AssertionError: AEST
...

=========== SYSTEM ===========

$ cat /proc/version 
Linux version 2.4.19 (root@haplo) (gcc version 2.95.3
20010315 (SuSE)) #4 SMP Tue Mar 4 09:23:24 CET 2003

Logged In: YES 
user_id=33168

What OS are you using?  Redhat 6.2, perhaps?  Can you test
patch 762934?  http://python.org/sf/762934

Logged In: YES 
user_id=269193

suse 7.1 or 7.2. kernel 2.19.
i cannot apply the patch just now, but i will try tomorrow.

tt.

Logged In: YES 
user_id=80475

Brett, is this related to the other failures?

Logged In: YES 
user_id=357491

If you are referring to bug #763047 and its cohort #763052, then 
no, I don't think so.  Those I think were an actual bug in the code.  
But there *is* a possibility since _strptime does call time.tzset 
when it calculates what timezones it knows about.

I am unassigning from myself since I have never touched 
time.tzset (don't remember who wrote time.tzset off the top of my 
head but it is a Python 2.3 feature).

Logged In: YES 
user_id=357491

Torsten, can you please try the patch that Neal pointed out?  We 
are approaching the release of Python 2.3 (by the end of the 
month) and it would be nice if this bug was settled before it goes 
out.

Logged In: YES 
user_id=269193

sorry, problem! hard drive scambled.
i have to re-install python anyway. i will see if the test
fails again, and then i try to apply the patch.

Logged In: YES 
user_id=80475

Tonight, test_time also failed for me and then worked on the 
next pass.  Am using WinME and Py2.3b2+.

Logged In: YES 
user_id=269193

no, sorry, no success!

 * re-compiled python, as expected the test failed again.
 * patch -p0 <../tzset4.diff
 * made a "make distclean"
 * ./configure again, looked nice, no chached stuff.
 * make 
 * make test
 >>> failed again !!!

anything i could check to help?

Logged In: YES 
user_id=357491

Barry says you need to do the following to truly test the patch:

- check out the head
- make distclean
- apply the patch
- autoreconf
- ./configure --with-pydebug
- make test

Apparently autoreconf regenerates something for autoconf and 
that has to be done.  Learn something new everyday.  Can you 
give that a shot, Torsten?  If that still fails it is going to take some 
work to figure this one out.

Logged In: YES 
user_id=357491

I uploaded a new version of the patch.  Give it a try and see what 
happens if you could.

Logged In: YES 
user_id=827666

Hello.

I just downloaded 2.3c1. I failed test_time as well. I was
going to submit a new bug, but then I saw this thread. I
hope this is the right place.

test_time
test test_time failed -- Traceback (most recent call last):
  File
"/home/tim/Download/Python-2.3c1/Lib/test/test_time.py",
line 107, in test_tzset
    self.failUnless(time.tzname[1] == 'AEDT',
str(time.tzname[1]))
  File "/home/tim/Download/Python-2.3c1/Lib/unittest.py",
line 268, in failUnless
    if not expr: raise self.failureException, msg
AssertionError: AEST

227 tests OK.
1 test failed:
    test_time
27 tests skipped:
    test_aepack test_al test_bsddb185 test_bsddb3 test_cd
test_cl
    test_curses test_email_codecs test_gl test_imgfile
    test_linuxaudiodev test_macfs test_macostools test_nis
    test_normalization test_ossaudiodev test_pep277
test_plistlib
    test_scriptpackages test_socket_ssl test_socketserver
    test_sunaudiodev test_timeout test_unicode_file
test_urllibnet
    test_winreg test_winsound
Those skips are all expected on linux2.
make: *** [test] Error 1

For what it's worth, time seems to work...

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

$ cat /proc/version 
Linux version 2.4.20 (root@mrbun) (gcc version 2.95.3
20010315 (release)) #11 Sat Nov 30 05:52:58 EST 2002

Tim

Logged In: YES 
user_id=827666

Hi.

I just thought I'd mention that I got the same results with
2.3c2.

Tim

Logged In: YES 
user_id=12800

I'm not sure there's anything we can do about this for
Python 2.3 final.  Lowering the priority, although I will
add a note in known bugs.html page.

Logged In: YES 
user_id=490655

Just a comment..  I was experimenting with ways to make the test pass 
(slack 8.1, glib 2.1.3, gcc 3.0.2), and by telling it to test tzname[1] with 
"AEST" it will pass (though I'm sure this violates whatever the test is for in 
the first place), but it fails on the time.daylight test (daylight = 0 when 
should = 1).

Interestingly enough, if I 
change:
test_time.py:103: environ['TZ'] = victoria
  
to
test_time.py:103: environ['TZ'] = 'Australia/Victoria'
  (as 
per the 'time' module documentation)

  it fails the same way, 
except the tztime[0,1] = EST,EST instead of AEST,*AEST (*as is the 
cause for the failed test in the first place).

Bear in mind I know jack 
diddly about how the timezone stuff works, so I'm just playing, and 
thought I'd share my results.. (=

Logged In: YES 
user_id=490655

Sorry to pollute here, but just an FYI:
Setting line 103 
to:
environ['TZ'] = 'Australia/Victoria'
and changing lines 106-
107 to:
self.failUnless(time.tzname[0] == 'EST', 
str(time.tzname[0]))
self.failUnless(time.tzname[1] == 'EST', 
str(time.tzname[1]))

all subsequent tests pass just fine, and 
the module test completes successfully.

Granted, I don't know 
what the difference between EST and EDT is, but it works. 
(=

With line 103, setting environ['TZ'] as the var 'victoria' and 
setting line 107 to AEST, that test passes, but as I mentioned before, the 
time.daylight test fails.

Logged In: YES 
user_id=357491

It's that time again!  =)  Patch #762934 has another patch to test; 
the one called "configure.in.patch.kbk".  Please give it a shot and 
respond with what OS you used and a pass or failure.  Remember 
you need to run autoreconf before you run 'configure'.  The main 
test is to see if time.tzset exists after compilation.

Logged In: YES 
user_id=357491

The patch #762934 has been applied to fix this problem.

Closing this bug report.