I tried very hard to reproduce this scenario today and came to the
conclusion that what the user does must be very wrong. The test he
posted wrongly assumes that a java.sql.Date object created in one
timezone produces the same LocalDate object when toLocalDate() is
invoked in a different timezo
I'm not sure exactly where the fault lies (java.util versus java.sql), but
we should certainly help hide that if we reasonably can. But conceptually,
milliseconds on a DATE (no time) makes zero sense at all. So where does
the milliseconds come from?
It is also possible that the db is (incorrectl
Hi,
I recently helped one of our users with a MySQL timezone issue, and I
realized that the default legacy timezone handling is to be avoided.
Basically, you want to set this "useLegacyDatetimeCode' configuration
property to false.
for more details, check out this article:
https://vladmihalcea.
The driver just has to use the available `getDate/getMonth/getYear`
functions of the java.sql.Date class, because they're what's intended
by the API. The problem is that the MySQL driver tries to do more than
that, when their database doesn't even support time zones.
On 14 March 2017 at 12:17, Chr
So you are saying that it should be the JDBC drivers responsibility to
add the JVMs local timezone offset to the java.sql.Date so the
normalization can subtract the offset again? I would be ok with that,
but is it really the responsibility of the JDBC driver?
Mit freundlichen Grüßen,
-
What java.sql.Date does is wrong for many reasons (mostly because it
extends java.util.Date which is a horrible API), but I think Vlad laid
it out pretty well why it's a JDBC driver configuration problem and
not a Hibernate problem. If you simply rely on the Java API to use
handle it's l own TZ con
