Re: java.sql.Timestamp: Bug or...
Hole wrote:
For everyone is interested in the TimeZone thing:
If your original poor UTC string date passes unharmed any "silent&
transparent" conversion from a TimeZone to your local default one and
you have to insert that Timestamp in your database, remember to use
the method CallableStatement.setTimestamp() that accepts a Calendar
instance with the proper TimeZone adjusted, since the JDBC Driver will
use your default TimeZone when it constructs the TIMESTAMP.
Even better, since 'CallableStatement' is intended for stored procedure use
'PreparedStatement', intended to execute SQL commands. I don't understand the
wisdom of 'CallableStatement' if you're not invoking stored procedures.
<http://java.sun.com/javase/6/docs/api/java/sql/PreparedStatement.html#setDate(int,
java.sql.Date, java.util.Calendar)>
allows you to use a 'TimeZone' other than the default.
As a minute or two with the Javadocs would reveal.
Retrieval can use the corresponding
<http://java.sun.com/javase/6/docs/api/java/sql/ResultSet.html#getDate(int,
java.util.Calendar)>
and of course there are parallel
<http://java.sun.com/javase/6/docs/api/java/sql/PreparedStatement.html#setTimestamp(int,
java.sql.Timestamp, java.util.Calendar)>
and
<http://java.sun.com/javase/6/docs/api/java/sql/ResultSet.html#getTimestamp(java.lang.String,
java.util.Calendar)>
Note further that 'CallableStatement' inherits these setter methods.
--
Lew