I'll submit a change when I have time. Thanks
-----Original Message-----
From: Bruce Snyder [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 10, 2003 4:34 PM
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] Default time zones in date/time/timestamp
fields
This one time, at band camp, Warner, Jack said:
WJ>A former consultant at my company posted a few messages related to:
WJ>http://www.mail-archive.com/[EMAIL PROTECTED]/msg12080.html
WJ><http://www.mail-archive.com/[EMAIL PROTECTED]/msg12080.html>
WJ>
WJ>We still need a resolution to this. Currently castor does not use the
WJ>ResultSet.getDate(int, Calendar) (
WJ>http://java.sun.com/j2se/1.4/docs/api/java/sql/ResultSet.html#getDate(int,%2
WJ>0java.util.Calendar)
WJ><http://java.sun.com/j2se/1.4/docs/api/java/sql/ResultSet.html#getDate(int,%
WJ>20java.util.Calendar> ) and related methods that take a Calendar object to
WJ>specify the timezone of the data retrieved from the database when it is not
WJ>already specified in the data, so the "current" timezone is applied. This
WJ>makes for inconsistent results when the castor code is being executed on
WJ>machines with different timezones, e.g. we get 10-Mar-2003 00:00:00 CST in
WJ>one case and 10-Mar-2003 00:00:00 EST in another case for the same data.
WJ>Clearly those 2 values are not the same.
WJ>
WJ>If we were using straight JDBC, we would be using the getDate et al methods
WJ>and pass a Calendar object containing the timezone of the server hosting the
WJ>data, which is not necessarily the same as that of the machine running the
WJ>castor code.
WJ>
WJ>Alternatively we could theoretically modify our objects' setXXX(Date)
WJ>methods that castor ends up calling, and adjust the values there based on
WJ>the timezone we desire them to be represented in, but management at my
WJ>company would like to pursue getting Castor to support the notion of a
WJ>"desired time zone" to apply to retrieved date/time values that have no time
WJ>zone already as originally read.
WJ>
WJ>Basically for Castor to change it only involves the modification of
WJ>org.exolab.castor.jdo.engine.SQLTypes class to pass a Calendar as the second
WJ>argument to the 3 places that call rs.getDate/getTime/getTimestamp, and some
WJ>way of specifying the timezone we want that Calendar to represent, either
WJ>thru a system property, a static JDO method, a new tag/property in the
WJ>mapping.xml or database.xml file, or some other way you might come up with.
WJ>Please consider this and reply. Thank you.
Jack,
First off, please see the Guidelines for Code Contribution :
http://www.castor.org/cvs.html#Guidelines-For-Code-Contribution
Second, here are the steps I recommend that you take in order to implement
these changes:
1) Regarding the property for setting the desired time zone,
please place a new property at the end of src/etc/castor.properties
(e.g. org.exolab.castor.jdo.timezone).
2) Add a method to SQLTypes named loadTimeZone() to grab the property. See
SQLTypes#loadLobBufferSize() for an example.
3) Modify the necessary methods in SQLTypes to make use of the loadTimeZone()
method.
I would say that there is no need to write a CTF-JDO test case because
the testing of this functionality because regression of the other tests
will pick up any problems.
Bruce
--
perl -e 'print unpack("u30","<0G)[EMAIL PROTECTED]&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
***********************************************************************************
WARNING: All e-mail sent to and from this address will be received or
otherwise recorded by the A.G. Edwards corporate e-mail system and is
subject to archival, monitoring or review by, and/or disclosure to,
someone other than the recipient.
************************************************************************************
