Re: [Zope] DateTime strftime problem
[ Andreas Jung wrote:]
--On 7. November 2005 14:41:43 +0100 Jürgen Herrmann>
zope 2.8.3, should i upgrade to 2.8.4 first?
This is possibly related to bug #1780 (and other related timezone bugs). Unfortunately the timezone handling in Zope was and is always a mess...unlikely that it will be ever fixed, sorry.
-aj
then i will fix it, if i can. i need that functionality, because we have users from different time zones that access a shared calendar. thanks for the hint anyway, regards, juergen herrmann _______________________________________________________________________
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
--On 7. November 2005 14:59:44 +0100 Jürgen Herrmann <Juergen.Herrmann@XLhost.de> wrote:
then i will fix it, if i can. i need that functionality, because we have users from different time zones that access a shared calendar.
The "if i can" might be the reason why is not fixed yet :-) But feel free to submit patches, good luck. -aj
On 11/7/05, Jürgen Herrmann <Juergen.Herrmann@xlhost.de> wrote:
then i will fix it, if i can. i need that functionality, because we have users from different time zones that access a shared calendar.
I don't know if this helps, but it might: Python had a good module called datetime. Most likely, you want to use that instead. There are no standard timezone implementation, but Zope 3 has one you might be able to use. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
[ Lennart Regebro wrote:]
On 11/7/05, Jürgen Herrmann <Juergen.Herrmann@xlhost.de> wrote:
then i will fix it, if i can. i need that functionality, because we have users from different time zones that access a shared calendar.
I don't know if this helps, but it might:
Python had a good module called datetime. Most likely, you want to use that instead. There are no standard timezone implementation, but Zope 3 has one you might be able to use.
1. what do you mean by HAD? seems to be there still and looks quite useable. 2. if this works as expected, why not make DateTime a wrapper around python datetime objects? is DateTime optimized for storage in the zodb (maybe a separate question to the zodb-dev list)? what was the intention to create DateTime anyway, if there's a python pendant already? regards, juergen herrmann _______________________________________________________________________
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
--On 7. November 2005 15:22:56 +0100 Jürgen Herrmann <Juergen.Herrmann@XLhost.de> wrote:
2. if this works as expected, why not make DateTime a wrapper around python datetime objects? is DateTime optimized for storage in the zodb (maybe a separate question to the zodb-dev list)? what was the intention to create DateTime anyway, if there's a python pendant already?
This idea had been discussed already for Python 2.4 or Python 2.5 I think. Since 100% compatibility could not be guaranteed, it was never implemented -aj
--On 7. November 2005 15:36:26 +0100 Andreas Jung <lists@andreas-jung.com> wrote:
--On 7. November 2005 15:22:56 +0100 Jürgen Herrmann <Juergen.Herrmann@XLhost.de> wrote:
2. if this works as expected, why not make DateTime a wrapper around python datetime objects? is DateTime optimized for storage in the zodb (maybe a separate question to the zodb-dev list)? what was the intention to create DateTime anyway, if there's a python pendant already?
This idea had been discussed already for Python 2.4 or Python 2.5
I mean: Zope 2.4 or Zope 2.5, not Python .... -aj
[ Andreas Jung wrote:]
--On 7. November 2005 15:36:26 +0100 Andreas Jung <lists@andreas-jung.com> wrote:
--On 7. November 2005 15:22:56 +0100 Jürgen Herrmann <Juergen.Herrmann@XLhost.de> wrote:
2. if this works as expected, why not make DateTime a wrapper around python datetime objects? is DateTime optimized for storage in the zodb (maybe a separate question to the zodb-dev list)? what was the intention to create DateTime anyway, if there's a python pendant already?
This idea had been discussed already for Python 2.4 or Python 2.5
I mean: Zope 2.4 or Zope 2.5, not Python ....
-aj
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 _______________________________________________________________________
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
[ 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
Jürgen Herrmann wrote:
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.
That would be entirely unsuprising *sigh* Chris - hey! it passes the tests! it must be right! yeah... -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
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 fg@nuxeo.com
zope 2.7.8's DateTime::strftime() looks like this: def strftime(self, format): # Format the date/time using the *local timezone representation*. return strftime(format, safelocaltime(self.timeTime())) it seems that my assumption about strftime's behaviour was incorrect. why do we have time zones at all, if strftime always uses the machine's local time zone? would this be better off in a new method, similar to strftime but respecting the DateTime's current time zone? (that's what i need) submitting a patch with my implementation is likely to be refused because it changes long standing behaviour... on the other hand, if DateTime's strftime should behave as similar as possible to datetime's strftime, it should respect the timezone information attached to it. honestly i don't know what to do... i can just make this a monkeypatch and only use it myself, but that just didn't feel like "the right thing to do" :) regards, juergen herrmann [ Florent Guillaume wrote:]
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 fg@nuxeo.com _______________________________________________ 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 )
_______________________________________________________________________
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
Jürgen Herrmann wrote at 2005-11-9 13:38 +0100:
zope 2.7.8's DateTime::strftime() looks like this:
def strftime(self, format): # Format the date/time using the *local timezone representation*. return strftime(format, safelocaltime(self.timeTime()))
it seems that my assumption about strftime's behaviour was incorrect. why do we have time zones at all, if strftime always uses the machine's local time zone?
Zope's "strftime" is simply broken. Forget about it. It should be simple to implement your own version in Python (and I think someone already did). Once you did, donate the implementation to Zope.... -- Dieter
[ Dieter Maurer wrote:]
Jürgen Herrmann wrote at 2005-11-9 13:38 +0100:
zope 2.7.8's DateTime::strftime() looks like this:
def strftime(self, format): # Format the date/time using the *local timezone representation*. return strftime(format, safelocaltime(self.timeTime()))
it seems that my assumption about strftime's behaviour was incorrect. why do we have time zones at all, if strftime always uses the machine's local time zone?
Zope's "strftime" is simply broken.
Forget about it. It should be simple to implement your own version in Python (and I think someone already did). Once you did, donate the implementation to Zope....
-- Dieter
ok, i guess i can fix strftime. will take some time to change the tests and add some comments. i'd like to report with the patch here first and get some comments, to avoid "don't do"s... already came across another python bug in strptime, that reports a format error, if %Z (timezone *omg*) is in the format string and you give it value different to UTC... this IS getting interesting :) thanks for all your help... regards, juergen _______________________________________________________________________
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
Andreas Jung wrote:
This idea had been discussed already for Python 2.4 or Python 2.5 I think. Since 100% compatibility could not be guaranteed,
What? you mean it wouldn't be broken? ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On 11/7/05, Jürgen Herrmann <Juergen.Herrmann@xlhost.de> wrote:
1. what do you mean by HAD? seems to be there still and looks quite useable.
I mean has. :)
2. if this works as expected, why not make DateTime a wrapper around python datetime objects?
Because that is a lot of work to make that work in a way that doesn't instantly break every Zope instance in existance.
what was the intention to create DateTime anyway, if there's a python pendant already?
It didn't exist then. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
participants (6)
-
Andreas Jung -
Chris Withers -
Dieter Maurer -
Florent Guillaume -
Jürgen Herrmann -
Lennart Regebro