Details
New Feature
Closed
Major
Description
Castor has a method for forcing what timezone to read dates with. (See http://www.castor.org/types.html#SQL-Dates-and-Default-Timezone). The problem is that this setting has not effect on what you write to the database. So you don't have round-trip integrity of date, time and timestamp values.
For example, if I set the timezone to be 'UTC' in the castor.properties. When I write a date to the database it will write it to the database as 'PDT' (my local timezone) cause this is what the JDBC driver defaults too. But when I read it back it will convert it to 'UTC' because castor is is only converting on reads. So my dates will be 8 hours off of what they should be. Anyway, not the clearest explanation...sorry. I've attached a modified SQLTypeInfos.java file that should address the issue.
Attachments
Issue Links
| This issue is depended upon by: | ||||
| CASTOR-1285 | Complete support for Calendar during reads/writes to apply to various type conversions |
|
|
|
Activity
Brian, it looks like your patch is a valid one (after inserting a few break; statements throughout your additions .. 
), but unfortunately it falls short from providing a complete solution, as with Castor a java.util.Date property of a Java class about to be persisted can be mapped to numeric and string columns as well. In my view, one needs to add code to SQLEngine.toSql() to set the Calendar instance on the java.util.Date object instance before it's being converted subsequently.
), but unfortunately it falls short from providing a complete solution, as with Castor a java.util.Date property of a Java class about to be persisted can be mapped to numeric and string columns as well. In my view, one needs to add code to SQLEngine.toSql() to set the Calendar instance on the java.util.Date object instance before it's being converted subsequently. I found Werner's test case in castor/src/bugs/jdo/bug1276. Rather than wrestle with getting setup to run that test, I created a test using my existing application to check 'datetime'/'timestamp' fields. The test I ran is at http://vars.svn.sourceforge.net/viewvc/vars/trunk/vars/src/test/java/org/mbari/jdo/castor/TestDateStorage.java?view=markup. The patch works, at least for my cases.
I added one more test method to src/bugs/jdo/bug1276/TestTemplate.java and attached the new file. Sorry I didn't generate a unified patch; it's tough to generate a patch for a patch that hasn't been applied to SVN yet . To commit it to SVN you have to apply your patch (patch-C1276-20070130.txt) then copy the new TestTemplate.java file to src/bugs/jdo/bug1276/. Unfortunately, the added test method only checks 'timestamp' SQL data types. I'm under a dealine crunch so I'll try to get tests for 'date' and 'time' SQL data types done 'REAL SOON'.
. To commit it to SVN you have to apply your patch (patch-C1276-20070130.txt) then copy the new TestTemplate.java file to src/bugs/jdo/bug1276/. Unfortunately, the added test method only checks 'timestamp' SQL data types. I'm under a dealine crunch so I'll try to get tests for 'date' and 'time' SQL data types done 'REAL SOON'. Now that you mention the timezone setting in castor.properties I know what I missed Will come back with test updated result soon.
Will come back with test updated result soon. Hi Ralf,
Thanks for going through the contortions deed to run this test. This bug has been impacting me in a very painful ways, so I'm very relieved that you'll commit the patch. 
BTW, I have run this same test on Apache Derby, Oracle 10g and XE as well as SQL Server 2000 and they have all exhibited this time zone issue. That's very interesting about the MySQL driver though; I'll have to remember that.
BTW, I have run this same test on Apache Derby, Oracle 10g and XE as well as SQL Server 2000 and they have all exhibited this time zone issue. That's very interesting about the MySQL driver though; I'll have to remember that.
Thanks, Brian. In future, when attaching patches, can you please attach a unified patch only ?