Re: [Zope-dev] Possible DateTime timezone-related regression in Zope 2.12
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
> Hi,
>
> We have a failing test in plone.app.dexterity 1.0a7. This is simply
> trying to compare two dates:
>
> >>> from DateTime import DateTime
> >>> DateTime() > DateTime(md.CreationDate())
> True
>
> At least here in Australia, the second test fails. Right now, the
> following expressions are:
>
> DateTime(): DateTime('2010/01/10 11:20:24.718203 GMT+8')
> md.CreationDate(): '2010-01-10 11:19:57'
> DateTime(md.CreationDate()): DateTime('2010/01/10 11:19:57 GMT+0')
>
> On Zope 2.10, it's a different story:
>
> DateTime(): DateTime('2010/01/10 11:34:01.508 GMT+8')
> md.CreationDate(): '2010-01-10 11:24:42'
> DateTime(md.CreationDate()): DateTime('2010/01/10 11:24:42 GMT+8')
>
> Andi Zeidler looked into it briefly, and said the following:
>
> imho, this is due a bug in `DateTime` 2.12.0. the newer version behaves
> differently when it's initialized via a string representation of a date
> — it interprets the given date to be GMT while before it was taken to be
> from your local time zone:
>
> $ cd ~/plone/coredev/branches
> $ cat foo.py
> from DateTime import DateTime
> print DateTime('2010-01-09 00:34:37')
> $ 3.3/bin/zopepy foo.py
> 2010/01/09 00:34:37 GMT+1
> $ 4.0/bin/zopepy foo.py
> 2010/01/09 00:34:37 GMT+0
>
> 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?
Why would you be parsing the 'CreationDate' return value (a string)
instead of just using the 'created' value (already a DateTime)?
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkuRU9sACgkQ+gerLs4ltQ4ItQCgpgfgzo9SKBjx4cXVxPnps4h6
8RAAoKrV/Z2K+WLPBzuWd+XhZHlA7pRW
=CryU
-END PGP SIGNATURE-
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Possible DateTime timezone-related regression in Zope 2.12
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/ - i...@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/
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Possible DateTime timezone-related regression in Zope 2.12
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/ - i...@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/ ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Possible DateTime timezone-related regression in Zope 2.12
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/ - i...@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/ ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Possible DateTime timezone-related regression in Zope 2.12
Laurence Rowe wrote: > 2010/1/10: >> -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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Possible DateTime timezone-related regression in Zope 2.12
2010/1/10 : > -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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Possible DateTime timezone-related regression in Zope 2.12
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 Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Possible DateTime timezone-related regression in Zope 2.12
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? Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Possible DateTime timezone-related regression in Zope 2.12
Hi,
We have a failing test in plone.app.dexterity 1.0a7. This is simply
trying to compare two dates:
>>> from DateTime import DateTime
>>> DateTime() > DateTime(md.CreationDate())
True
At least here in Australia, the second test fails. Right now, the
following expressions are:
DateTime(): DateTime('2010/01/10 11:20:24.718203 GMT+8')
md.CreationDate(): '2010-01-10 11:19:57'
DateTime(md.CreationDate()): DateTime('2010/01/10 11:19:57 GMT+0')
On Zope 2.10, it's a different story:
DateTime(): DateTime('2010/01/10 11:34:01.508 GMT+8')
md.CreationDate(): '2010-01-10 11:24:42'
DateTime(md.CreationDate()): DateTime('2010/01/10 11:24:42 GMT+8')
Andi Zeidler looked into it briefly, and said the following:
imho, this is due a bug in `DateTime` 2.12.0. the newer version behaves
differently when it's initialized via a string representation of a date
— it interprets the given date to be GMT while before it was taken to be
from your local time zone:
$ cd ~/plone/coredev/branches
$ cat foo.py
from DateTime import DateTime
print DateTime('2010-01-09 00:34:37')
$ 3.3/bin/zopepy foo.py
2010/01/09 00:34:37 GMT+1
$ 4.0/bin/zopepy foo.py
2010/01/09 00:34:37 GMT+0
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?
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
