> With Oracle-only JDBC, I prefer to only use java.sql.Timestamp
> and handle date truncation myself, especially because of JDBC's weird
> behaviour related to timezones when using java.sql.Date. Feel free to
> answer this question, if you know it :-)
> http://stackoverflow.com/questions/9202857/timezones-in-sql-date-vs-java-sql-date
If I haven't made any mistakes, this is what I get so far when looking
at the driver's code:
When setting a Date on a prepared statement, it creates an
oracle.sql.DATE object, constructed from the Date and a Calendar.
The Calendar is obtained using
Calendar.getInstance(getDefaultTimeZone()) where getDefaultTimeZone()
generally falls back on TimeZone.getDefault().
The internal bytes contained by the DATE object are taken by setting
the Date on the Calendar, and then getting the year, month and date
fields.
You can get a feel for the actual date that is sent by running those 2
chunks of code.
java.util.Calendar calendar =
java.util.Calendar.getInstance(TimeZone.getTimeZone("CET"));
calendar.setTime(new java.util.Date(112, 1, 15));
System.out.println(calendar.get(java.util.Calendar.YEAR) + ", " +
calendar.get(java.util.Calendar.MONTH) + ", " +
calendar.get(java.util.Calendar.DATE));
java.util.Calendar calendar =
java.util.Calendar.getInstance(TimeZone.getTimeZone("GMT"));
calendar.setTime(new java.util.Date(112, 1, 15));
System.out.println(calendar.get(java.util.Calendar.YEAR) + ", " +
calendar.get(java.util.Calendar.MONTH) + ", " +
calendar.get(java.util.Calendar.DATE));
I don't know the retrieving side so I don't consider my answer
complete enough to post it, though I suspect no conversion take place.
Note that in our application, we do the following at the start but it
looks a lot like a work around:
TimeZone.setDefault(TimeZone.getTimeZone("GMT"));
Hope this helps,
-Christopher
