Today I started testing Zope 2.9.6. After the upgrade I noticed that some calendar data generated from Oracle was wrong. After some investigation I found that Zope 2.9.6 seems to assign a timezone of GMT+0 when none is specified rather than using the server's timezone. For example, the following SQL query to an oracle database: select TO_DATE('12-13-2006 01:00','MM-DD-YYYY HH:MI') from dual Under 2.9.5 returns: 2006/12/13 01:00:00 US/Eastern Under 2.9.6 returns: 2006/12/13 01:00:00 GMT+0 There was clearly no time zone defined in the query, and it's the same Oracle server. Is this an intended change? We have hundreds of developers working independently within our system so it's not possible to adapt each application to account for this change. Any advice on moving to Zope 2.9.6? In the mean time I my try to back port specific bug fixes into 2.9.5. Thank you, -- Brian Brinegar Web Systems Developer Engineering Computer Network
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Brinegar wrote:
Today I started testing Zope 2.9.6. After the upgrade I noticed that some calendar data generated from Oracle was wrong. After some investigation I found that Zope 2.9.6 seems to assign a timezone of GMT+0 when none is specified rather than using the server's timezone.
For example, the following SQL query to an oracle database:
select TO_DATE('12-13-2006 01:00','MM-DD-YYYY HH:MI') from dual
Under 2.9.5 returns:
2006/12/13 01:00:00 US/Eastern
Under 2.9.6 returns:
2006/12/13 01:00:00 GMT+0
There was clearly no time zone defined in the query, and it's the same Oracle server.
Is this an intended change? We have hundreds of developers working independently within our system so it's not possible to adapt each application to account for this change.
Any advice on moving to Zope 2.9.6? In the mean time I my try to back port specific bug fixes into 2.9.5.
That backwards incompatibility has been reverted on the 2.9 branch. You might try updating the 'DateTime.py' file from SVN: http://svn.zope.org/*checkout*/Zope/branches/2.9/lib/python/DateTime/DateTim... Eventually the feature will be re-added with a configuration option to enable it. 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.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFgb3P+gerLs4ltQ4RAp2DAKDWmqql37CWa5VDYRIJoTLJ3wWtAACg2Kok MjwihrnRUhXthDj5LCLFliY= =CQvY -----END PGP SIGNATURE-----
Brian Brinegar wrote: Today I started testing Zope 2.9.6. After the upgrade I noticed that
Tres Seaver <tseaver@...> writes: That backwards incompatibility has been reverted on the 2.9 branch. You might try updating the 'DateTime.py' file from SVN:
http://svn.zope.org/*checkout*/Zope/branches/2.9/lib/python/DateTime/DateTim... y?content-type=text%2Fplain&rev=71544
Eventually the feature will be re-added with a configuration option to enable it.
Thanks! Replacing the 'DateTime.py' file in the 2.9.6 release with the one in the link provided above solved my problem too. <RANT> It is very frustrating to have these problems in a *mature* product and waste a full 2 days searching for this resolution. My users of the site don't like seeing everything they update with a modified time of "localtime + <timezone_offest>" (for me Canada/Eastern that's localtime-5 hours). What struck be rather strange is the Calendar porlet could display the event date and times correctly but the Event portlet and the rest of the site pages were incorrect. </RANT> Thanks again!
participants (3)
-
Brian Brinegar -
dschultz -
Tres Seaver