[Zope-Coders] Linux Test Results - Zope 2.6 branch - failures:1

[Lennart Regebro]

From: <zope-tests@squishdot.org>
> FAIL: rfc822 conversion
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "testDateTime.py", line 263, in testRFC822
>   File "/usr/local/lib/python2.1/unittest.py", line 273, in
failUnlessEqual
>     raise self.failureException, (msg or '%s != %s' % (first, second))
> AssertionError: Thu, 02 May 2002 08:00:00 +0100 != Thu, 02 May 2002
08:00:00 +0000
> ----------------------------------------------------------------------
> Ran 1657 tests in 310.146s
>

This is a bug in the tests. I'm starting to dislike my idea on how
DateTime.rfc822() is working.

The big problem is that DateTime fetches some timezone information from the
system, no matter what the timezone in the date is. This information is
necessary in creating the rfc822 string, mainly because there is no way of
converting the timezone setting of the DateTime object into an offset.

That makes it hard to create tests, since it's hard to test everything,
since you can't really test being in another timezone than the one you
actually are in. So, for example, how do you test that the rfc822() works if
you are running the test in Iceland, where they have no DST at all? Well,
you clearly need to be completely independant of where the test is run. But,
on the other hand, you can't be independant of it.

At the moment, I can see three ways out of this:
1. Somebody  rewrites DateTime from scratch. (yeah, right) :-)
2. We skip the tests for rfc822() because they lull you into a flase sense
of security.
3. We rewrite DateTime.rfc822() to *always* return '-0000' as the time zone
(which means, no zone information availiable).

Whaddayousay?

Best Regards

Lennart Regebro
Torped Strategi och Kommunikation AB