Jeremy Hylton wrote:
On Thu, 2003-06-12 at 18:24, Brett C. wrote:
test test_strptime failed -- Traceback (most recent call last): File "/home/jeremy/src/python/dist/src/Lib/test/test_strptime.py", line 203, in test_compile self.failUnless(found, "Matching failed on '%s' using '%s' regex" % File "/home/jeremy/src/python/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: Matching failed on 'Thu 05 Jun 2003 05:46:43 PM EDT' using '(?P<a>Mon|Tue|Wed|Thu|Fri|Sat|Sun)\s*(?P<d>3[0-1]|[1-2]\d|0[1-9]|[1-9]| [1-9])\s*(?P<b>Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)\s*(?P<Y>\d\d\d\d)\s*(?P<I>1[0-2]|0[1-9]|[1-9]):(?P<M>[0-5]\d|\d):(?P<S>6[0-1]|[0-5]\d|\d)\s*(?P<p>AM|PM)\s*EST' regex
Jeremy, are you still getting this failure? How about anyone else?
Strangely enough, I am. I've run the tests irregularly over the last couple of weeks without seeing it. But today I ran the tests and say the failure.
Is there any reason you expect that this is a transient bug?
Timezone info is fetched from time.tzname so it should be consistent but can change between platforms. Below is from an email I sent a while back. Can you try what I suggest and let me know the results?
Until then, Jeremy, can you see if it passes if you back out the recent changes that modified timezone handling (I think it was just the last one; added GMT and UTC acknowledgement as well as handilng the timezone better, or so I thought)?
So it is actually two versions ago; version 1.16 is what I would like you to run (1.17 tried to make timzone handling more robust and 1.18 calls time.tzset in case there was a locale change since time.tzname does not get changed without the call). Can you also run the below line of code and paste in what gets spit out?:: >>> import time, _strptime; time.daylight; time.tzname; _strptime.LocaleTime().timezone; time.daylight; time.tzname; time.tzset() -Brett