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 )