Re: [Zope-dev] Possible DateTime timezone-related regression in Zope 2.12
2010/1/10 <zopyxfilter@gmail.com>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Martin Aspeli wrote:
Wichert Akkerman wrote:
On 2010-1-10 04:36, Martin Aspeli wrote:
so in your test, `DateTime(md.CreationDate())` will always be the current time, but with an implicitly added 'GMT+0' while `DateTime()` will be the current time in your local time zone. so if i'm not mistaken, on plone 4.0 the test with fail for you an me (in 'GMT+x' time zones) and pass in the u.s. fun! :)
Does anyone know if this change was deliberate, or what may have happened? Have you looked at http://zope3.pov.lt/trac/log/Zope/trunk/lib/python/DateTime?rev=95999
for hints?
Yes, there are various timezone related changes, e.g.
http://zope3.pov.lt/trac/changeset/81213/Zope/trunk/lib/python/DateTime
http://zope3.pov.lt/trac/changeset/85830/Zope/trunk/lib/python/DateTime
It's hard to know whether this was an intended change or not, and if so, how to deal with the breakage in a way that's compatible with 2.10 and 2.12.
I blame Laurence. :-p
Better blame DateTime :-) Fixing one issue in DateTime is likely to trigger another new bug. The DateTime is just fragile.
I believe the current behaviour is intentional to preserve backwards compatibility. See the discussion starting here: https://mail.zope.org/pipermail/zope-dev/2007-October/030042.html Maybe it was 'fixed' on 2.10 branch some time later. Laurence
Laurence Rowe wrote:
2010/1/10<zopyxfilter@gmail.com>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Martin Aspeli wrote:
Wichert Akkerman wrote:
On 2010-1-10 04:36, Martin Aspeli wrote:
so in your test, `DateTime(md.CreationDate())` will always be the current time, but with an implicitly added 'GMT+0' while `DateTime()` will be the current time in your local time zone. so if i'm not mistaken, on plone 4.0 the test with fail for you an me (in 'GMT+x' time zones) and pass in the u.s. fun! :)
Does anyone know if this change was deliberate, or what may have happened? Have you looked at http://zope3.pov.lt/trac/log/Zope/trunk/lib/python/DateTime?rev=95999
for hints? Yes, there are various timezone related changes, e.g.
http://zope3.pov.lt/trac/changeset/81213/Zope/trunk/lib/python/DateTime
http://zope3.pov.lt/trac/changeset/85830/Zope/trunk/lib/python/DateTime
It's hard to know whether this was an intended change or not, and if so, how to deal with the breakage in a way that's compatible with 2.10 and 2.12.
I blame Laurence. :-p Better blame DateTime :-) Fixing one issue in DateTime is likely to trigger another new bug. The DateTime is just fragile.
I believe the current behaviour is intentional to preserve backwards compatibility. See the discussion starting here: https://mail.zope.org/pipermail/zope-dev/2007-October/030042.html
Maybe it was 'fixed' on 2.10 branch some time later.
Sorry, just to be clear - which behaviour is correct? The 2.10 one or the 2.12 one? My vote would go for the 2.10 one - in the absence of timezone information, assume local timezone, not GMT. If we agree on that, is it clear what needs to be changed for this to work? Can we also agree that it's very bad for 2.10 and 2.12 to exhibit different behaviour here? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On 11.01.10 01:47, Martin Aspeli wrote:
Laurence Rowe wrote:
I believe the current behaviour is intentional to preserve backwards compatibility. See the discussion starting here: https://mail.zope.org/pipermail/zope-dev/2007-October/030042.html
Maybe it was 'fixed' on 2.10 branch some time later.
Sorry, just to be clear - which behaviour is correct? The 2.10 one or the 2.12 one?
imho, the one from 2.10. i think about anyone would expect to have a simple date given being interpreted as from their current time zone, no? also, look at the following (using `DateTime` 2.12): $ ~/plone/coredev/branches/4.0/bin/zopepy
from DateTime import DateTime now = DateTime() now == DateTime(now) True now == DateTime(now.ISO()) False
this is a _pretty_ behaviour, to say the least! :)
My vote would go for the 2.10 one - in the absence of timezone information, assume local timezone, not GMT.
+1, definitely.
If we agree on that, is it clear what needs to be changed for this to work?
yes, i believe it is. we need to revert Laurence' revert (http://zope3.pov.lt/trac/changeset/81213) and fix those BBB issues in another way.
Can we also agree that it's very bad for 2.10 and 2.12 to exhibit different behaviour here?
+1 andi -- zeidler it consulting - http://zitc.de/ - info@zitc.de friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 4.0 alpha released! -- http://plone.org/products/plone/
On 05.03.10 10:53, Andreas Zeidler wrote:
also, look at the following (using `DateTime` 2.12):
$ ~/plone/coredev/branches/4.0/bin/zopepy
from DateTime import DateTime now = DateTime() now == DateTime(now) True now == DateTime(now.ISO()) False
this is a _pretty_ behaviour, to say the least! :)
heh, that should have read "_pretty_ strange", btw... :) so, after some more reading and discussing this with Stefan, it seems the example should really use `ISO8601()` instead of `ISO()`. however, this fails as well: $ ~/plone/coredev/branches/4.0/bin/zopepy
from DateTime import DateTime now = DateTime() now == DateTime(now.ISO8601()) False now.ISO8601() '2010-03-05T11:06:09+01:00'
unlike stated in `DateTime.interfaces` the string returned `ISO8601` method does not contain the time zone. tres, do you have any comments on this? cheers, andi -- zeidler it consulting - http://zitc.de/ - info@zitc.de friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 4.0 alpha released! -- http://plone.org/products/plone/
On 05.03.10 11:10, Andreas Zeidler wrote:
now == DateTime(now.ISO8601()) False now.ISO8601() '2010-03-05T11:06:09+01:00'
unlike stated in `DateTime.interfaces` the string returned `ISO8601` method does not contain the time zone.
oops, it does, of course (i think i'm still a bit too tired :)). sorry about this! :) the above example fails, because `now` contains the microseconds, but `ISO8601` doesn't include them:
now - DateTime(now.ISO8601()) 1.9525578703703702e-06 now, DateTime(now.ISO8601()) (DateTime('2010/03/05 11:16:9.168701 GMT+1'), DateTime('2010/03/05 11:16:09 GMT+1'))
tres, do you have any comments on this?
nevermind, i think now it should be clear what needs to be changed... :)
cheers,
andi
-- zeidler it consulting - http://zitc.de/ - info@zitc.de friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 4.0 alpha released! -- http://plone.org/products/plone/
participants (3)
-
Andreas Zeidler -
Laurence Rowe -
Martin Aspeli