[Patches] [ python-Patches-762934 ] address test_time.py failures under Redhat 6.2

SourceForge.net noreply at sourceforge.net
Thu Sep 18 21:03:40 EDT 2003


Patches item #762934, was opened at 2003-06-29 17:44
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762934&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Stuart Bishop (zenzen)
Assigned to: Brett Cannon (bcannon)
Summary: address test_time.py failures under Redhat 6.2

Initial Comment:
A mangled version of this patch is also in bug:

    http://www.python.org/sf/728051



Looks like tzset(3) is broken under Redhat 6.2 in a way

that wasn't being detected by configure. This

patch adds stricter tzset(3) checking to configure.in.





----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2003-09-18 18:03

Message:
Logged In: YES 
user_id=357491

Kurt's patch has been checked in both to HEAD and release23-

maint.



Thanks, Kurt, for all your hard work.

----------------------------------------------------------------------

Comment By: Jordan Krushen (furie)
Date: 2003-09-17 10:51

Message:
Logged In: YES 
user_id=218883

I've tested kbk's patch on fresh installs of both RH 6.1 and 6.

2, and they both pass all (non-skipped) tests.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-08-07 20:11

Message:
Logged In: YES 
user_id=357491

OK, so Kurt's thinking and debugging all seem good to me.  I 

applied the patch and it worked correctly for me.  Can other 

people test it (not just Red Hat but also other platforms; OS X is 

covered by my test)?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-07-24 23:48

Message:
Logged In: YES 
user_id=357491

Thanks for the debugging work, Kurt.  I will take a good look at 

this when 2.4 dev starts.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2003-07-24 20:48

Message:
Logged In: YES 
user_id=149084

[kbk at float ~/PYSRC]$ ./python

Python 2.3c2 (#15, Jul 24 2003, 11:17:16)

[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2

Type "help", "copyright", "credits" or "license" for more information.

>>> import time   

>>> from os import environ

>>> victoria = 'AEST-10AEDT-11,M10.5.0,M3.5.0'

>>> environ['TZ'] = victoria

>>> time.tzset()

>>> time.tzname

('AEST', 'AEST')

>>>

=========================================

Hm!!  Try a couple of things to try to see what's going on:

=========================================

>>> victoria2 = 'AEST-10AEDT-11'

>>> environ['TZ'] = victoria2

>>> time.tzset()

>>> time.tzname

('AEST', 'AEDT')

>>>

>>> # try reversing the changeover

...

>>> victoria3 = 'AEST-10AEDT-11,M3.5.0,M10.5.0'

>>> environ['TZ'] = victoria3

>>> time.tzset()

>>> time.tzname

('AEST', 'AEDT')



===================================

ok, debug inittimezone:

===================================

Breakpoint 1, inittimezone (m=0x4014053c)

    at /home/kbk/PYTHON/python/dist/src/Modules/timemodule.c:608

608t = (time((time_t *)0) / YEAR) * YEAR;

(gdb) n

609p = localtime(&t);

(gdb) p asctime(localtime(&t))

$14 = 0x4013be00 "Wed Jan  1 16:00:00 2003\n"

(gdb) p localtime(&t)->tm_zone

$19 = 0x8162b78 "AEST"



[std time on Jan 1!! ...back up a day or so....]



(gdb) p t = t - 84000

$20 = 1041316800

(gdb) p localtime(&t)->tm_zone

$21 = 0x8162b90 "AEDT"

(gdb) p asctime(localtime(&t))

$22 = 0x4013be00 "Tue Dec 31 17:40:00 2002\n"

(gdb)



===================================

so Linux6.2 thinks AEDT switches to AEST in Jan, and six months

forward is still AEST.



xmas2002 is AEDT so config test passes but timemodule uses Jan 1

and flubs when setting tzname.



Need to do the config test later than xmas.

=====================================



*** Apply Patch SF 762934  configure.in.patch.kbk



======================================

autoreconf && ./configure && make clean && make OPT=-g



======================================

extract from configure log:

....

checking for broken nice()... yes

checking for working tzset()... no

checking for tv_nsec in struct stat... no

checking whether mvwdelch is an expression... yes

....

======================================



[kbk at float ~/PYSRC]$ ./python

Python 2.3c2 (#18, Jul 24 2003, 22:40:09)

[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2

Type "help", "copyright", "credits" or "license" for more information.

>>> from test import test_time

>>> test_time.test_main()

test_asctime (test.test_time.TimeTestCase) ... ok

test_clock (test.test_time.TimeTestCase) ... ok

test_conversions (test.test_time.TimeTestCase) ... ok

test_data_attributes (test.test_time.TimeTestCase) ... ok

test_sleep (test.test_time.TimeTestCase) ... ok

test_strftime (test.test_time.TimeTestCase) ... ok

test_strptime (test.test_time.TimeTestCase) ... ok

test_tzset (test.test_time.TimeTestCase) ... ok



------------------------------------------------------------

Ran 8 tests in 2.523s



OK

>>>



===================================

make test:

===================================

....

....

test_zlib

227 tests OK.

28 tests skipped:

    test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl

    test_curses test_email_codecs test_gl test_imgfile test_largefile

    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.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-07-22 16:04

Message:
Logged In: YES 
user_id=357491

Well, it is looking like tzset_AEST is not working as a solution.  

Hopefully Neal's patch will do the trick.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-07-22 15:46

Message:
Logged In: YES 
user_id=33168

See this mail for a possible fix. 

http://mail.python.org/pipermail/python-dev/2003-July/037116.html



Stuart, is that correct?  It fixes the problem on RedHat 6.2

and doesn't break on RedHat 9.  The change is to define YEAR

as 365 * 24 * 3600, instead of adding 6 hours.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-07-16 13:05

Message:
Logged In: YES 
user_id=44345

Works for me (Mac OS X)



----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-07-12 19:27

Message:
Logged In: YES 
user_id=357491

Quick update: I got autoreconf to work and it seems to work for 

me.  I also tested the C code in isolation and had no problems.  So 

I now I just need other people to apply the patch and say whether 

it works.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-07-12 16:01

Message:
Logged In: YES 
user_id=357491

Well, it didn't work for two people for Red Hat 6.2 .  Perhaps being 

more explicit for the test?  To give that a shot, I am uploading a 

patch that tests explicitly for AEDT as the daylight-savings 

timezone.  I snagged the code mostly from Modules/timemodule.c 

.



Now this is untested so there could be syntax problems.  I can't 

get a proper version of Autoconf to run on my system so I can run 

autoreconf.  Hopefully this will deal with the problem.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-07-10 07:29

Message:
Logged In: YES 
user_id=12800

This patch didn't break RH9.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-07-03 13:16

Message:
Logged In: YES 
user_id=357491

We can say it should fail under Linux, but we can't specify Red Hat 

6.2.



I am keeping an eye on this patch for bug  #763153, but I have to 

wait until the OP applies it and tests it.



Looking at the patch, beyond not realizing that the X-mas time 

was GMT initially and the unneeded variable assignments, the 

patch looks fine to me (might want to comment that tzset does not 

return a value; rather non-standard) although I am no autoconf 

expert and I am assuming it just compiles this C code and any 

problems it just says  it fails.



Neal, what OS are you  running?  If it is non-OS X (sorry, that's 

what I am running as well) can you give the patch a try?

----------------------------------------------------------------------

Comment By: Stuart Bishop (zenzen)
Date: 2003-07-01 20:51

Message:
Logged In: YES 
user_id=46639

This patch has only been tested under OS X.



I'm confident that it won't break other platforms.



I have no real way of proving that it addresses the problem it is 

supposed to solve, however, as I don't have access to a box that 

fails the tzset test in test_time.py.



The only reported platform that this is failing on is at

http://www.python.org/sf/728051, so we could just flag this

test as expected to fail on that platform, if someone knows how

to do that.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-07-01 20:03

Message:
Logged In: YES 
user_id=33168

Stuart, what boxes did you test this on?  How confident are

you that this won't break some other platform?  I'm asking

to try to determine if this should go into 2.3final (we only

have 1 release candidate before release) or if this should

wait for 2.3.1.  Thanks for all your work on tzset.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762934&group_id=5470



More information about the Patches mailing list