[ 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 :)
_______________________________________________________________________
>> XLhost.de - eXperts in Linux hosting <<
Jürgen Herrmann
Bruderwöhrdstraße 15b, DE-93051 Regensburg
Fon: +49 (0)700 XLHOSTDE [0700 95467833]
Fax: +49 (0)721 151 463027
WEB: http://www.XLhost.de
_______________________________________________
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 )
