Jeg har for nylig fundet ud af, at afhængigt af databasedriveren, der bruges, kan jOOQ udvise en mærkelig adfærd i DateTime-parsing. jOOQ returnerer offset dato og klokkeslæt som Z (UTC), selvom det ikke er
Specifikt i mit tilfælde resulterede brug af en anden Postgres-driver i, at DefaultBinding.java modtog et kalenderobjekt, der har et tidsstempel, men kalder toString på det for at parse. Det viste sig, at toString ikke udskriver tidszonen, så udledte jOOQ, at det var i lokal tid.
For mig var de stødende linjer i DefaultBinding.java (jeg brugte et tidsstempel med tidszone):
else if (type == OffsetDateTime.class) {
result = (T) offsetDateTime(ctx.resultSet().getString(ctx.index()));
}
Du kan være på en anden linje i den serie af andre hvis baseret på ikke at have en tidszone.
I min test fandt jeg også ud af, at ændring af systemtiden ændrede resultatet, men at ændre sessionstiden gjorde ingenting.
Heldigvis for mig løste et skift til standard Postgres-driveren problemet. Hvis det ikke gjorde det, ville jeg se på at overbelaste bindingen for OffsetDateTime for at rette brugen af toString og dets tilhørende stripning af den relevante tidszone. Du bliver muligvis nødt til at følge den vej, desværre, medmindre du også bruger en SQL-driver, der kunne opgraderes eller udskiftes. Eller du kan gemme det med en tidszone og derefter konvertere til den ønskede tidszone, når du indlæser fra databasen.