Why do I get dates back one off when using JOOQ? - mysql

Question

We are using jOOQ to talk to a MySQL database containing this table:
CREATE TABLE daily_sessions
(
session_id INT AUTO_INCREMENT NOT NULL,
user_id VARCHAR(45) NULL,
day date NULL,
CONSTRAINT PK_DAILY_SESSIONS PRIMARY KEY (session_id)
);
We have enabled the support for the JSR-310 types, so we are using LocalDate on the Java/Kotlin side to map this.
What we are seeing is that the day field gets retrieved with an offset of one day. The inserts and select statements logged by jOOQ seem to indicate it is doing the right thing when binding SQL parameters, but when the result comes back it shows the day before:
2019-04-05 09:32:08 [Gax-20 ] DEBUG o.j.i.DefaultConnectionProvider - setting auto commit : false
2019-04-05 09:32:08 [Gax-20 ] DEBUG o.j.tools.LoggerListener - Executing query : select `daily_sessions`.`session_id`, `daily_sessions`.`user_id`, `daily_sessions`.`day` from `daily_sessions` where (`daily_sessions`.`user_id` = ? and `daily_sessions`.`day` = ?)
2019-04-05 09:32:08 [Gax-20 ] DEBUG o.j.tools.LoggerListener - -> with bind values : select `daily_sessions`.`session_id`, `daily_sessions`.`user_id`, `daily_sessions`.`day` from `daily_sessions` where (`daily_sessions`.`user_id` = '87a09702-0d6b-485c-895c-986f238e1d30' and `daily_sessions`.`day` = {d '2011-11-11'})
2019-04-05 09:32:08 [Gax-20 ] DEBUG o.j.tools.LoggerListener - Fetched result : +----------+------------------------------------+----------+
2019-04-05 09:32:08 [Gax-20 ] DEBUG o.j.tools.LoggerListener - : |session_id|user_id |day |
2019-04-05 09:32:08 [Gax-20 ] DEBUG o.j.tools.LoggerListener - : +----------+------------------------------------+----------+
2019-04-05 09:32:08 [Gax-20 ] DEBUG o.j.tools.LoggerListener - : | 13|87a09702-0d6b-485c-895c-986f238e1d30|2011-11-10|
2019-04-05 09:32:08 [Gax-20 ] DEBUG o.j.tools.LoggerListener - : +----------+------------------------------------+----------+
2019-04-05 09:32:08 [Gax-20 ] DEBUG o.j.tools.LoggerListener - Fetched row(s) : 1
2019-04-05 09:32:08 [Gax-20 ] DEBUG o.j.i.DefaultConnectionProvider - commit
2019-04-05 09:32:08 [Gax-20 ] DEBUG o.j.i.DefaultConnectionProvider - setting auto commit : true
2019-04-05 09:32:08 [Gax-20 ] DEBUG c.z.hikari.pool.PoolBase - HikariPool-1 - Reset (isolation) on connection com.mysql.cj.jdbc.ConnectionImpl#4af95547
Notice how the select filters on 2011-11-11, but the result table shows 2011-11-10.
This is from a test, run on my local machine (UTC+10), against the standard mysql Docker image running locally as well.
Despite using DATE, I assume we are running into some timezone issue, but I cannot reproduce the problem by talking JDBC directly. I tried running this in the same setup the other tests run in:
#Test
fun testDateColumn() {
DriverManager.getConnection("jdbc:mysql://localhost:8890/rewards-test", "root", "").use { con ->
con.createStatement().use { stmt ->
stmt.execute("insert into `daily_sessions` (`user_id`, `day`) values ('a20add98-5a93-417f-a771-848757b2b1f8', {d '2011-11-11'})")
}
con.createStatement().use { stmt ->
stmt.executeQuery("select `daily_sessions`.`session_id`, `daily_sessions`.`user_id`, `daily_sessions`.`day` from `daily_sessions` where (`daily_sessions`.`user_id` = 'a20add98-5a93-417f-a771-848757b2b1f8' and `daily_sessions`.`day` = {d '2011-11-11'})").use { rs ->
while (rs.next()) {
println("${rs.getString(3)} - ${rs.getDate(3)}")
}
}
}
}
}
This code produces the expected output. The SQL statements are straight copies from the jOOQ logs. There must be something else jOOQ does that I do not understand.
Do I need to configure timezones in jOOQ somehow? Or am I missing anything else?
Update
As proposed by Lukas in the comments, I tried changing my JDBC test to use prepared statements:
#Test
fun testDateColumn() {
DriverManager.getConnection("jdbc:mysql://localhost:8890/rewards-test", "root", "").use { con ->
con.prepareStatement("insert into `daily_sessions` (`user_id`, `day`) values (?, ?)").use { ps ->
ps.setString(1, "a20add98-5a93-417f-a771-848757b2b1f8")
ps.setDate(2, Date.valueOf(LocalDate.of(2011, 11, 11)))
ps.execute()
}
con.prepareStatement("select `daily_sessions`.`session_id`, `daily_sessions`.`user_id`, `daily_sessions`.`day` from `daily_sessions` where (`daily_sessions`.`user_id` = ? and `daily_sessions`.`day` = ?)").use { ps ->
ps.setString(1, "a20add98-5a93-417f-a771-848757b2b1f8")
ps.setDate(2, Date.valueOf(LocalDate.of(2011, 11, 11)))
ps.executeQuery().use { rs ->
while (rs.next()) {
println("${rs.getString(3)} - ${rs.getDate(3)}")
}
}
}
}
}
This indeed produces the wrong results, the output is 2011-11-10 for both the string and date variants. It seems there is something I don't understand in JDBC.
Update 2
The code above can be fixed by passing the default java.util.Calendar instance as a third parameter to the setDate method, i.e. replacing both cases above with:
ps.setDate(2, Date.valueOf(LocalDate.of(2011, 11, 11)), Calendar.getInstance())
Using this we see the expected output, whereas the plain version without the third parameter does not.
The JavaDoc of the setDate method says the absence of the Calendar object will cause the VM's time zone to be used, which seems to be exactly the same the definition of Calendar.getInstance() specifies, which seems to indicate nothing should change.

Answer 1

This turned out to be a known bug in the MySQL JDBC driver. My fix was to revert to a much older version which predates the problem.