I\'m using jooq (v3.11.9) to access a MySQL database that is running in UTC time. I\'ve using generated entities and am using JSR-310 time types. The option I\'m using in my con
I recently found that depending on the database driver being used, jOOQ can exhibit some strange behavior in DateTime parsing. jOOQ returns offset date time as Z (UTC) even though it's not
Specifically, in my case, using a different Postgres driver resulted in DefaultBinding.java receiving a calendar object that has a timestamp, but calling toString on it in order to parse. Turns out, toString does not print the timezone, then jOOQ inferred that it was in local time.
For me, the offending lines in DefaultBinding.java (I was using a timestamp with timezone) were:
else if (type == OffsetDateTime.class) {
result = (T) offsetDateTime(ctx.resultSet().getString(ctx.index()));
}
You may be on a different line in that series of else ifs based on not having a time zone.
In my testing, I also found that changing the system time changed the result, but changing the session time did nothing.
Fortunately for me, a switch to the standard Postgres driver resolved the problem. If it didn't, I was going to look in to overloading the binding for OffsetDateTime to fix the use of toString and it's associated stripping of the relevant time zone. You may need to pursue that path, unfortunately, unless you too are using a SQL driver than could be upgraded or replaced. Or, you could store it with a timezone and then convert to the desired timezone when you load from the database.