J'ai récemment découvert qu'en fonction du pilote de base de données utilisé, jOOQ peut présenter un comportement étrange dans l'analyse DateTime. jOOQ renvoie la date et l'heure du décalage sous la forme Z (UTC) même si ce n'est pas le cas
Plus précisément, dans mon cas, l'utilisation d'un pilote Postgres différent a entraîné la réception par DefaultBinding.java d'un objet de calendrier doté d'un horodatage, mais en appelant toString pour l'analyser. Il s'avère que toString n'imprime pas le fuseau horaire, puis jOOQ a déduit qu'il était à l'heure locale.
Pour moi, les lignes incriminées dans DefaultBinding.java (j'utilisais un horodatage avec fuseau horaire) étaient :
else if (type == OffsetDateTime.class) {
result = (T) offsetDateTime(ctx.resultSet().getString(ctx.index()));
}
Vous pouvez être sur une ligne différente dans cette série d'autre si basée sur le fait de ne pas avoir de fuseau horaire.
Lors de mes tests, j'ai également constaté que la modification de l'heure du système modifiait le résultat, mais que la modification de l'heure de la session ne faisait rien.
Heureusement pour moi, un passage au pilote Postgres standard a résolu le problème. Si ce n'était pas le cas, j'allais chercher à surcharger la liaison pour OffsetDateTime pour corriger l'utilisation de toString et sa suppression associée du fuseau horaire pertinent. Vous devrez peut-être suivre cette voie, malheureusement, à moins que vous n'utilisiez vous aussi un pilote SQL qui pourrait être mis à niveau ou remplacé. Ou, vous pouvez le stocker avec un fuseau horaire, puis le convertir dans le fuseau horaire souhaité lorsque vous le chargez à partir de la base de données.
