The DateTime implementation in Zope is notoriously undertested and
underspecified when it comes to time zones. Until recently strftime was
quite buggy too, and as you saw it has been recoded in terms of the python
datetime implementation now that it exists. It's very possible that a bug
was introduced at that point, it would be useful to check with Zope 2.7's
DateTime. Or the bug has always been there.
It think it's a good thing if DateTime can behave more regularly, which
means be more in line with python's datetime, in corner cases.
Please submit a patch to the collector. It probably will be included in 2.9
but not 2.8 which is strictly in maintenance mode, unless you convince us
that it's very unlikely that code would change behavior as a result.
Florent
Jürgen Herrmann wrote:
[ Jürgen Herrmann wrote:]
i looked at the source of DateTime::strftime(), surpirse, surprise :)
strftime uses python's datetime class and it's strftime method!
but no care is taken at this time for timezone information, so i
decided to code a tzinfo subclass for datetime that can represent
fixed offset from gmt (no dst) and hand one such instance to
datetime.fromtimestamp(). seems like this code is working correctly now.
i'll run it against some tests tomorrow and report back on the results.
regards, juergen herrmann
if i run the DateTime testsuite against my patched version:
======================================================================
ERROR: Checks strftime in dates <= 1900 or >= 2038
----------------------------------------------------------------------
Traceback (most recent call last):
File "/usr/lib/python2.4/unittest.py", line 260, in run
testMethod()
File "/home/bliss/zope/lib/python/DateTime/tests/testDateTime.py", line
366, in testStrftimeFarDates
self.assertEqual(dt.strftime('%d/%m/%Y'), '30/01/1900')
File "/home/bliss/zope/lib/python/DateTime/DateTime.py", line 1542, in
strftime
ds = datetime.fromtimestamp(self._t+offsetsecs, tzi).strftime(format)
ValueError: timestamp out of range for platform time_t
======================================================================
ERROR: Checks time zone in dates <= 1900 or >= 2038
----------------------------------------------------------------------
Traceback (most recent call last):
File "/usr/lib/python2.4/unittest.py", line 260, in run
testMethod()
File "/home/bliss/zope/lib/python/DateTime/tests/testDateTime.py", line
374, in testZoneInFarDates
self.assertEqual(dt1.strftime('%d/%m/%Y %H:%M'),
dt2.strftime('%d/%m/%Y %H:%M'))
File "/home/bliss/zope/lib/python/DateTime/DateTime.py", line 1542, in
strftime
ds = datetime.fromtimestamp(self._t+offsetsecs, tzi).strftime(format)
ValueError: timestamp out of range for platform time_t
======================================================================
FAIL: strftime timezone testing
----------------------------------------------------------------------
Traceback (most recent call last):
File "/usr/lib/python2.4/unittest.py", line 260, in run
testMethod()
File "/home/bliss/zope/lib/python/DateTime/tests/testDateTime.py", line
361, in testStrftimeTZhandling
self.assertEqual(dt_string, dt_localstring)
File "/usr/lib/python2.4/unittest.py", line 333, in failUnlessEqual
raise self.failureException, \
AssertionError: '2003-11-19 17:32 -0215' != '2003-11-19 21:47 GMT+0100'
----------------------------------------------------------------------
Ran 32 tests in 13.056s
th first two are obviously side effects from using a timestamp for
the instantiation of my datetime object, could be fixed, not the focus
for now.
the third one brings me back to my initial question:
what is this code snippet supposed to return?
d = DateTime('2005/04/03 02:01 UTC')
d.toZone('GMT+1').strftime('%Y/%m/%d %H:%M %Z')
'2005/04/03 03:01 GMT+0100'
is this correct?
if so, the i would tend to say, the testcase was written to pass with
wrong strftime() behaviour. (*duck*)
regards, juergen herrmann
ps: tomorrow has been shifted to today due to a bug in my brain's
datetime implementation, so i ran the tests today :)
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
_______________________________________________
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
