Subject Re: PreparedStatement.setTimestamp(int, Timestamp, Calendar) issue - comments needed
Author rwilcom
First, I would like to thank Roman for the great attention he gave
to this important issue. He worked diligently and professionally
with me to come to a resolution! Great job!

Second, about the parameter name - although I first thought
that 'fix_for_ron' would make a great name I will suggest a few
others and comment on the suggestions already made:

invert_time_zone - short but a bit misleading in its meaning.

mysql_timezone_interpretation - should defintily not be centric to
another database, there are likely other databases that do the same
interpretation so the parameter should remain generic.

write_uses_local_timezone - this one is good, captures what is
happening, although the calculation is not only on the write
(setTimezone w/ Calendar) but can also be on the read (getTimezone
w/ Calendar). So if you go with this one I would
use 'uses_local_timezone'.

other suggestions:


Thanks for everyone's participation on this one - thanks again Roman!


--- In, "Roman Rokytskyy"
<rrokytskyy@a...> wrote:
> Hi All,
> Probably you have read the discussion about the meaning of the
> mentioned method between me and Ron. We have continued the
> off-list and here's the results:
> We have found out that there is no agreement among driver
developers how to
> interpret the phrase "With a Calendar object, the driver can
calculate the
> timestamp taking into account a custom timezone." from the JDBC
> specification.
> For example Oracle treats it as "write data into the database
converting the
> specified timestamp into the specified timezone" (e.g. calendar
> target time zone). In turn MySQL developers interpret this as "the
> is specified in the time zone of the passed calendar, write data
into the
> database using local time zone".
> Example:
> we have following timestamp "31-07-2004 19:48:54 CEST" (CEST is
> PreparedStatement ps = ....
> Calendar cal = Calendar.getInstance(TimeZone.getTimeZone("UTC"));
> Timestamp ts = new Timestamp(new Date().getTime());
> ps.setTimestamp(1, ts, cal);
> In Oracle the stored timestamp would be "31-07-2004 18:48:54", in
MySQL that
> would be "31-07-2004 20:48:54".
> So far JayBird uses MySQL interpretation of the specification.
However Ron
> managed to convince me that it is wrong. Reason is that timestamp
> does not know anything about time zones - time is stored as
> after 1.1.1970 0:00:00.000 UTC. This is general contract in Java.
> MySQL interpretation can be translated as "number of milliseconds
in UTC in
> CEST". This seems to be nonsense.
> Therefore I would like to change the behavior of the driver to
follow the
> common sense (and Oracle) interpretation. This might affect
> applications. I will introduce a new connection parameter
> "invert_time_zone", when it is specified, driver will use MySQL
> interpretation.
> Comments? Suggestions?
> Thanks!
> Roman