Re: SVN: Zope/trunk/lib/python/DateTime/tests/testDateTime.py Fix test. According to http://en.wikipedia.org/wiki/ISO_8601
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Laurence Rowe wrote:
Log message for revision 80922: Fix test. According to http://en.wikipedia.org/wiki/ISO_8601 If no time zone information is given with a time, the time zone is assumed to be in some conventional local time zone.
If I understand correctly, the trunk has had a BBB-incompatible change to the semantics of the DateTime constructor: In Zope 2.10.x (as well as 2.9x, 2.8x, and 2.7x):
from DateTime.DateTime import DateTime DateTime('2006/01/01')._tz 'US/Eastern' DateTime('2006/01/01 UTC')._tz 'Universal' DateTime('2006-01-01')._tz 'GMT+0'
On the trunk:
from DateTime.DateTime import DateTime DateTime('2006/01/01') DateTime('2006/01/01') DateTime('2006/01/01')._tz 'US/Eastern' DateTime('2006/01/01 UTC')._tz 'UTC' DateTime('2006-01-01')._tz 'US/Eastern'
I strongly disagreed with the argument for that change (http://www.zope.org/Collectors/Zope/2109), because it broke the semantics of the class, based on long-established use in Zope: datetime strings which used ISO notation, but provided no explicit timezone, were assigned 'GMT+0' as the timezone. The trunk should be reverted to preserve the old behavior, which may be relied on by third-party applications. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHI7U1+gerLs4ltQ4RAraFAJwKFa2DOCYn3dPzBM8jXnlajEcrpACeKalL BxeHK/EzDNqV5tT0yY0J76I= =HL8g -----END PGP SIGNATURE-----
--On 27. Oktober 2007 18:01:25 -0400 Tres Seaver <tseaver@palladion.com> wrote:
DateTime('2006-01-01')._tz 'US/Eastern'
Yeah, that's completely odd.
I strongly disagreed with the argument for that change (http://www.zope.org/Collectors/Zope/2109), because it broke the semantics of the class, based on long-established use in Zope: datetime strings which used ISO notation, but provided no explicit timezone, were assigned 'GMT+0' as the timezone.
Totally agreed.
Is this right issue? The URL redirection to LP points me to this: <https://bugs.launchpad.net/zope2/+bug/143701>
The trunk should be reverted to preserve the old behavior, which may be relied on by third-party applications.
Jup, either revert the change or fix it. Andreas
Andreas Jung wrote:
--On 27. Oktober 2007 18:01:25 -0400 Tres Seaver <tseaver@palladion.com> wrote:
DateTime('2006-01-01')._tz 'US/Eastern'
Yeah, that's completely odd.
But standards compliant. The previous behaviour was contrary to the specification. According to http://en.wikipedia.org/wiki/ISO_8601 "If no time zone information is given with a time, the time zone is assumed to be in some conventional local time zone."
I strongly disagreed with the argument for that change (http://www.zope.org/Collectors/Zope/2109), because it broke the semantics of the class, based on long-established use in Zope: datetime strings which used ISO notation, but provided no explicit timezone, were assigned 'GMT+0' as the timezone.
Totally agreed.
However if we must preserve this bug for backwards compatibility then we must. (This bugfix would not change the interpretation of existing pickles).
Is this right issue? The URL redirection to LP points me to this:
<https://bugs.launchpad.net/zope2/+bug/143701>
The trunk should be reverted to preserve the old behavior, which may be relied on by third-party applications.
Jup, either revert the change or fix it.
Andreas
'Fixed' in r81213. Laurence
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Laurence Rowe wrote:
Andreas Jung wrote:
--On 27. Oktober 2007 18:01:25 -0400 Tres Seaver <tseaver@palladion.com> wrote:
DateTime('2006-01-01')._tz 'US/Eastern' Yeah, that's completely odd.
But standards compliant. The previous behaviour was contrary to the specification. According to http://en.wikipedia.org/wiki/ISO_8601
"If no time zone information is given with a time, the time zone is assumed to be in some conventional local time zone."
When your users are scattered across the internet, there *is* no single cnventional local time which will not surprise some / most of them; the timezone of the location in which the server happens to reside is completely irrelevant to a user. Zope has therefore adopted the convention that "local time" in Zope is GMT for ISO-spelled strings (the "slash" form uses the OS-supplied default timezone, again for backward-compatibility; the ISO spelling was added later).
I strongly disagreed with the argument for that change (http://www.zope.org/Collectors/Zope/2109), because it broke the semantics of the class, based on long-established use in Zope: datetime strings which used ISO notation, but provided no explicit timezone, were assigned 'GMT+0' as the timezone. Totally agreed.
However if we must preserve this bug for backwards compatibility then we must. (This bugfix would not change the interpretation of existing pickles).
The issue is not about pickles, but about code, and user interfaces, whose meanings have changed.
(http://www.zope.org/Collectors/Zope/2109), Is this right issue? The URL redirection to LP points me to this:
<https://bugs.launchpad.net/zope2/+bug/143701>
The trunk should be reverted to preserve the old behavior, which may be relied on by third-party applications. Jup, either revert the change or fix it.
Andreas
'Fixed' in r81213.
Thank you. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHJ6Zq+gerLs4ltQ4RAomIAJ0fcczrGkXCc2CY0I9VEFxdNSyi5wCg0i/z IR+DvtM0eVL7kWol55+H/m8= =sBPV -----END PGP SIGNATURE-----
participants (3)
-
Andreas Jung -
Laurence Rowe -
Tres Seaver