[Zope-dev] Re: Weird test failures with DateTime
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
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Weird test failures with DateTime
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Weird test failures with DateTime
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Weird test failures with DateTime
On Sun, 27 Nov 2005 07:40:36 -0800, Philipp von Weitershausen
[EMAIL PROTECTED] 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
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Weird test failures with DateTime
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.
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Weird test failures with DateTime
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Weird test failures with DateTime
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
