Issue 763153: unit test test_time failed (original) (raw)

Issue763153

Created on 2003-06-30 12:35 by towi, last changed 2022-04-10 16:09 by admin. This issue is now closed.

Messages (18)
msg16719 - (view)	Author: Torsten Will (towi)	Date: 2003-06-30 12:35
=== 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
msg16720 - (view)	Author: Neal Norwitz (nnorwitz) *	Date: 2003-06-30 15:15
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
msg16721 - (view)	Author: Torsten Will (towi)	Date: 2003-06-30 17:56
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.
msg16722 - (view)	Author: Raymond Hettinger (rhettinger) *	Date: 2003-07-01 02:38
Logged In: YES user_id=80475 Brett, is this related to the other failures?
msg16723 - (view)	Author: Brett Cannon (brett.cannon) *	Date: 2003-07-01 05:10
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).
msg16724 - (view)	Author: Brett Cannon (brett.cannon) *	Date: 2003-07-09 17:15
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.
msg16725 - (view)	Author: Torsten Will (towi)	Date: 2003-07-09 18:30
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.
msg16726 - (view)	Author: Raymond Hettinger (rhettinger) *	Date: 2003-07-10 04:37
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+.
msg16727 - (view)	Author: Torsten Will (towi)	Date: 2003-07-10 07:58
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?
msg16728 - (view)	Author: Brett Cannon (brett.cannon) *	Date: 2003-07-10 17:11
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.
msg16729 - (view)	Author: Brett Cannon (brett.cannon) *	Date: 2003-07-13 02:28
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.
msg16730 - (view)	Author: Tim Heaney (theaney)	Date: 2003-07-22 03:09
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
msg16731 - (view)	Author: Tim Heaney (theaney)	Date: 2003-07-27 23:04
Logged In: YES user_id=827666 Hi. I just thought I'd mention that I got the same results with 2.3c2. Tim
msg16732 - (view)	Author: Barry A. Warsaw (barry) *	Date: 2003-07-29 03:38
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.
msg16733 - (view)	Author: The LinuxDuck (thelinuxduck)	Date: 2003-07-31 16:30
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.. (=
msg16734 - (view)	Author: The LinuxDuck (thelinuxduck)	Date: 2003-07-31 16:41
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.
msg16735 - (view)	Author: Brett Cannon (brett.cannon) *	Date: 2003-08-08 03:13
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.
msg16736 - (view)	Author: Brett Cannon (brett.cannon) *	Date: 2003-09-19 01:07
Logged In: YES user_id=357491 The patch #762934 has been applied to fix this problem. Closing this bug report.