Weird test failures with DateTime
Hi, I've recently been seeing weird DateTime test failures on all Zope 2 branches since 2.7 (see below). Any idea what I'm doing wrong? My system is OSX 10.3 with a self-compiled Python 2.4.1 (through darwinports). My system timezone, as you can see, is GMT+0800 (Beijing time). philipp@bender:~/dev/Zope$ python test.py -s DateTime Running tests at level 1 Running unit tests: Running: . Failure in test testAddPrecision (DateTime.tests.testDateTime.DateTimeTests) Traceback (most recent call last): File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/unittest.py", line 260, in run testMethod() File "/Users/philipp/dev/Zope/lib/python/DateTime/tests/testDateTime.py", line 61, in testAddPrecision dt) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/unittest.py", line 333, in failUnlessEqual raise self.failureException, \ AssertionError: 2005/11/26 19:22:40.649 US/Central ...... Failure in test testConstructor5 (DateTime.tests.testDateTime.DateTimeTests) Traceback (most recent call last): File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/unittest.py", line 260, in run testMethod() File "/Users/philipp/dev/Zope/lib/python/DateTime/tests/testDateTime.py", line 89, in testConstructor5 self.assertEqual(str(dt), str(dt1), (dt, dt1)) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/unittest.py", line 333, in failUnlessEqual raise self.failureException, \ AssertionError: (DateTime('2005/11/26 19:22:40.687 US/Central'), DateTime('2005/11/26 05:22:40.687 US/Central')) ........... Failure in test testRFC822 (DateTime.tests.testDateTime.DateTimeTests) Traceback (most recent call last): File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/unittest.py", line 260, in run testMethod() File "/Users/philipp/dev/Zope/lib/python/DateTime/tests/testDateTime.py", line 328, in testRFC822 self.assertEqual(dts[5], "%+03d%02d" % divmod( (-offset/60), 60) ) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/unittest.py", line 333, in failUnlessEqual raise self.failureException, \ AssertionError: '-0600' != '+0800' .... Failure in test testSubtraction (DateTime.tests.testDateTime.DateTimeTests) Traceback (most recent call last): File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/unittest.py", line 260, in run testMethod() File "/Users/philipp/dev/Zope/lib/python/DateTime/tests/testDateTime.py", line 138, in testSubtraction self.assertEqual(dt1, dt3, (dt, dt1, dt2, dt3)) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/unittest.py", line 333, in failUnlessEqual raise self.failureException, \ AssertionError: (DateTime('2005/11/26 19:23:18.686 US/Central'), DateTime('2005/11/23 01:59:25.081 US/Central'), DateTime('2005/11/26 19:23:18.686 US/Central'), DateTime('2005/11/23 15:59:25.081 US/Central')) .......... Ran 32 tests with 4 failures and 0 errors in 38.183 seconds.
On 26 Nov 2005, at 11:43, Philipp von Weitershausen wrote:
Hi,
I've recently been seeing weird DateTime test failures on all Zope 2 branches since 2.7 (see below). Any idea what I'm doing wrong? My system is OSX 10.3 with a self-compiled Python 2.4.1 (through darwinports). My system timezone, as you can see, is GMT+0800 (Beijing time).
Running the tests under current 2.7/2.8 branches with Python 2.3.5 on OS X 10.4.3 things run fine: -------------------------------------------------- tiny:/usr/local/zope/28Instance jens$ bin/zopectl test --libdir /usr/ local/zope/opt/Zope-2.8-branch/lib/python DateTime Running tests via: /usr/local/bin/python /usr/local/zope/opt/Zope-2.8- branch/bin/test.py -v --config-file /usr/local/zope/28Instance/etc/ zope.conf --libdir /usr/local/zope/opt/Zope-2.8-branch/lib/python DateTime Running unit tests at level 1 Running unit tests from /usr/local/zope/opt/Zope-2.8-branch/lib/python Parsing /usr/local/zope/28Instance/etc/zope.conf ................................ ---------------------------------------------------------------------- Ran 32 tests in 23.396s OK --------------------------------------------------- However, I am noticing that on the current Zope 2.9 branch, trying to build the software fails completely. The "configure" script works fine, but the "make" step does not seem to do anything at all. There is no error output, and all that's in the directory set as the -- prefix is the makefile: ---------------------------------------------------- tiny:/usr/local/zope/opt/Zope-2.9-branch jens$ make "/usr/local/bin/python2.4" "/usr/local/zope/src/Zope-2.9-branch/ setup.py" \ build_ext -i running build_ext Zope built. Next, do 'make install' (or 'make instance' to run a Zope instance directly from the build directory). tiny:/usr/local/zope/opt/Zope-2.9-branch jens$ ls makefile ----------------------------------------------------- INSTALL.txt still shows the "configure/make/make install" instructions and I was under the impression this was still supposed to work. How does everyone else build 2.9? jens
Jens Vagelpohl wrote:
Hi,
I've recently been seeing weird DateTime test failures on all Zope 2 branches since 2.7 (see below). Any idea what I'm doing wrong? My system is OSX 10.3 with a self-compiled Python 2.4.1 (through darwinports). My system timezone, as you can see, is GMT+0800 (Beijing time).
Running the tests under current 2.7/2.8 branches with Python 2.3.5 on OS X 10.4.3 things run fine:
-------------------------------------------------- tiny:/usr/local/zope/28Instance jens$ bin/zopectl test --libdir /usr/ local/zope/opt/Zope-2.8-branch/lib/python DateTime Running tests via: /usr/local/bin/python /usr/local/zope/opt/Zope-2.8- branch/bin/test.py -v --config-file /usr/local/zope/28Instance/etc/ zope.conf --libdir /usr/local/zope/opt/Zope-2.8-branch/lib/python DateTime Running unit tests at level 1 Running unit tests from /usr/local/zope/opt/Zope-2.8-branch/lib/python Parsing /usr/local/zope/28Instance/etc/zope.conf ................................ ---------------------------------------------------------------------- Ran 32 tests in 23.396s
OK ---------------------------------------------------
Yes, I know that everyone else is not seeing the failures. That's why I'm wondering why I do...
However, I am noticing that on the current Zope 2.9 branch, trying to build the software fails completely. The "configure" script works fine, but the "make" step does not seem to do anything at all.
Yes it does. It compiles the C extensions.
There is no error output, and all that's in the directory set as the -- prefix is the makefile:
---------------------------------------------------- tiny:/usr/local/zope/opt/Zope-2.9-branch jens$ make "/usr/local/bin/python2.4" "/usr/local/zope/src/Zope-2.9-branch/ setup.py" \ build_ext -i running build_ext
Zope built. Next, do 'make install' (or 'make instance' to run a Zope instance directly from the build directory).
tiny:/usr/local/zope/opt/Zope-2.9-branch jens$ ls makefile -----------------------------------------------------
INSTALL.txt still shows the "configure/make/make install" instructions and I was under the impression this was still supposed to work. How does everyone else build 2.9?
INSTALL.txt needs to be updated. A repository checkout and a tarball of Zope 2.9 will look not alike a lot. To build a tarball, you go through the ./configure; make; make install orgy. To build a repository checkout, you just do ./configure; make. Like said above, that'll build the C extensions. You can also create an in-place instance with "make instance". Philipp
On 26 Nov 2005, at 15:07, Philipp von Weitershausen wrote:
However, I am noticing that on the current Zope 2.9 branch, trying to build the software fails completely. The "configure" script works fine, but the "make" step does not seem to do anything at all.
Yes it does. It compiles the C extensions.
The real difference now is that I used to be able to create an empty directory from which to run configure and make, but now it only works when you sit inside the full source tree... So in order to do my usual "pristine source tree under src/, build under opt/" I must now copy the full source tree over. Annoying :/ jens
Jens Vagelpohl wrote:
On 26 Nov 2005, at 15:07, Philipp von Weitershausen wrote:
However, I am noticing that on the current Zope 2.9 branch, trying to build the software fails completely. The "configure" script works fine, but the "make" step does not seem to do anything at all.
Yes it does. It compiles the C extensions.
The real difference now is that I used to be able to create an empty directory from which to run configure and make, but now it only works when you sit inside the full source tree... So in order to do my usual "pristine source tree under src/, build under opt/" I must now copy the full source tree over. Annoying :/
Yes, the "out-of-place" build functionality, as we unofficially called it, is not supported anymore. Really, I was surprised to hear that people used this feature so much for checkouts. After all, I thought you want to *work* in a sandbox, not install from it or anything (otherwise you wouldn't need a sandbox...). Philipp
On 27 Nov 2005, at 15:49, Philipp von Weitershausen wrote:
The real difference now is that I used to be able to create an empty directory from which to run configure and make, but now it only works when you sit inside the full source tree... So in order to do my usual "pristine source tree under src/, build under opt/" I must now copy the full source tree over. Annoying :/
Yes, the "out-of-place" build functionality, as we unofficially called it, is not supported anymore. Really, I was surprised to hear that people used this feature so much for checkouts. After all, I thought you want to *work* in a sandbox, not install from it or anything (otherwise you wouldn't need a sandbox...).
Define "sandbox". For me it is not the checkout of the software itself, it is the built-out $SOFTWARE_HOME. It was a little easier to create several such sandboxes (e.g. one with Python 2.3.x, one with 2.4.x) using the "out of place" build. jens
Philipp von Weitershausen wrote:
I've recently been seeing weird DateTime test failures on all Zope 2 branches since 2.7 (see below). Any idea what I'm doing wrong? My system is OSX 10.3 with a self-compiled Python 2.4.1 (through darwinports). My system timezone, as you can see, is GMT+0800 (Beijing time).
I've figured this one out. The Chinese time zone is known as 'CST', but so is 'US/Central' as well. In fact, Mac OS X itself doesn't report the time zones to python consistently. When I set my time zone to Chicago time, time.tzname is ('CST', 'CST') and when I set my time zone to Shanghai time, it remains the same, even though it's a completely different time zone. DateTime.DateTimeZone._zmap can only pick one timezone to be mapped to the 'CST' name and it happens to choose 'US/Central' (which doesn't surprise me obviously). Running the tests with the operating system's time zone set to, say, CET works fine. Philipp
On Sun, 27 Nov 2005 07:40:36 -0800, Philipp von Weitershausen <philipp@weitershausen.de> wrote:
Philipp von Weitershausen wrote:
I've recently been seeing weird DateTime test failures on all Zope 2 branches since 2.7 (see below). Any idea what I'm doing wrong? My system is OSX 10.3 with a self-compiled Python 2.4.1 (through darwinports). My system timezone, as you can see, is GMT+0800 (Beijing time).
I've figured this one out. The Chinese time zone is known as 'CST', but so is 'US/Central' as well. In fact, Mac OS X itself doesn't report the time zones to python consistently. When I set my time zone to Chicago time, time.tzname is ('CST', 'CST') and when I set my time zone to Shanghai time, it remains the same, even though it's a completely different time zone. DateTime.DateTimeZone._zmap can only pick one timezone to be mapped to the 'CST' name and it happens to choose 'US/Central' (which doesn't surprise me obviously). Running the tests with the operating system's time zone set to, say, CET works fine.
Welcome to the wonderful US-centric world of the Zope DateTime module. I believe the same problem exists for Australian time zones which happen to share abbreviations with some obscure US time zone. ;) Posting from the US-ly yours, -- _____________________________________________________________________ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _____________________________________________________________________ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone
Alexander Limi wrote:
Philipp von Weitershausen wrote:
I've recently been seeing weird DateTime test failures on all Zope 2 branches since 2.7 (see below). Any idea what I'm doing wrong? My system is OSX 10.3 with a self-compiled Python 2.4.1 (through darwinports). My system timezone, as you can see, is GMT+0800 (Beijing time).
I've figured this one out. The Chinese time zone is known as 'CST', but so is 'US/Central' as well. In fact, Mac OS X itself doesn't report the time zones to python consistently. When I set my time zone to Chicago time, time.tzname is ('CST', 'CST') and when I set my time zone to Shanghai time, it remains the same, even though it's a completely different time zone. DateTime.DateTimeZone._zmap can only pick one timezone to be mapped to the 'CST' name and it happens to choose 'US/Central' (which doesn't surprise me obviously). Running the tests with the operating system's time zone set to, say, CET works fine.
Welcome to the wonderful US-centric world of the Zope DateTime module. I believe the same problem exists for Australian time zones which happen to share abbreviations with some obscure US time zone. ;)
Indeed. In fact, I think CST is one of those ;). pytz fortunately avoids these ambiguities by not knowing about these names. It only knows CST6CDT which seems to be the U.S. version of the time zone. Philipp ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
participants (3)
-
Alexander Limi -
Jens Vagelpohl -
Philipp von Weitershausen