Recientemente descubrí que, según el controlador de la base de datos que se utilice, jOOQ puede mostrar un comportamiento extraño en el análisis de DateTime. jOOQ devuelve la fecha y hora de compensación como Z (UTC) aunque no lo sea
Específicamente, en mi caso, el uso de un controlador de Postgres diferente resultó en que DefaultBinding.java recibiera un objeto de calendario que tiene una marca de tiempo, pero llamó a String para analizarlo. Resulta que toString no imprime la zona horaria, luego jOOQ infirió que estaba en la hora local.
Para mí, las líneas ofensivas en DefaultBinding.java (estaba usando una marca de tiempo con zona horaria) fueron:
else if (type == OffsetDateTime.class) {
result = (T) offsetDateTime(ctx.resultSet().getString(ctx.index()));
}
Es posible que te encuentres en una línea diferente en esa serie de otros casos basados en no tener una zona horaria.
En mis pruebas, también encontré que cambiar la hora del sistema cambió el resultado, pero cambiar la hora de la sesión no hizo nada.
Afortunadamente para mí, un cambio al controlador estándar de Postgres resolvió el problema. Si no fuera así, buscaría sobrecargar el enlace para OffsetDateTime para corregir el uso de toString y su eliminación asociada de la zona horaria relevante. Desafortunadamente, es posible que deba seguir ese camino, a menos que también esté utilizando un controlador SQL que podría actualizarse o reemplazarse. O bien, puede almacenarlo con una zona horaria y luego convertirlo a la zona horaria deseada cuando cargue desde la base de datos.
