Can someone (Roman) please confirm that the change for the
set/getTimestamp issue outlined in this thread will be included in
the next release of JayBird?

The next release is due to be out early ~September?

Thanks!
Ron

--- In Firebird-Java@yahoogroups.com, "rwilcom" <ron.wilcom@n...>
wrote:

> 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:
>
> uses_local_timezone
> calculate_using_local_timezone
> compute_using_local_timezone
> timestamp_uses_local_timezone
> timestamp_local_centric
> timestamp_is_local
>
>
> Thanks for everyone's participation on this one - thanks again

Roman!

>
> Ron
>
>
> --- In Firebird-Java@yahoogroups.com, "Roman Rokytskyy"
> <rrokytskyy@a...> wrote:
> > Hi All,
> >
> > Probably you have read the discussion about the meaning of the
> above
> > mentioned method between me and Ron. We have continued the
> discussion
> > 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
> specifies
> > target time zone). In turn MySQL developers interpret this

as "the

> timestamp
> > 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
> GMT+01).
> >
> > 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

> object
> > does not know anything about time zones - time is stored as
> milliseconds
> > after 1.1.1970 0:00:00.000 UTC. This is general contract in

Java.

> Therefore
> > 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
> existing
> > applications. I will introduce a new connection parameter
> > "invert_time_zone", when it is specified, driver will use MySQL
> > interpretation.
> >
> > Comments? Suggestions?
> >
> > Thanks!
> > Roman