Jag upptäckte nyligen att beroende på vilken databasdrivrutin som används kan jOOQ uppvisa något konstigt beteende i DateTime-analys. jOOQ returnerar offset datumtid som Z (UTC) även om det inte är
Specifikt, i mitt fall, resulterade användningen av en annan Postgres-drivrutin i att DefaultBinding.java tog emot ett kalenderobjekt som har en tidsstämpel, men anropade toString på det för att analysera. Det visade sig att toString inte skriver ut tidszonen, sedan drog jOOQ slutsatsen att det var i lokal tid.
För mig var de stötande raderna i DefaultBinding.java (jag använde en tidsstämpel med tidszon):
else if (type == OffsetDateTime.class) {
result = (T) offsetDateTime(ctx.resultSet().getString(ctx.index()));
}
Du kan vara på en annan linje i den serien av andra omgångar baserat på att du inte har någon tidszon.
I mitt testande fann jag också att förändring av systemtiden förändrade resultatet, men att ändra sessionstiden gjorde ingenting.
Lyckligtvis för mig löste en byte till standard Postgres-drivrutinen problemet. Om det inte gjorde det, tänkte jag titta på att överbelasta bindningen för OffsetDateTime för att fixa användningen av toString och den tillhörande strippningen av den relevanta tidszonen. Du kan behöva följa den vägen, tyvärr, om du inte också använder en SQL-drivrutin som kan uppgraderas eller ersättas. Eller så kan du lagra den med en tidszon och sedan konvertera till önskad tidszon när du laddar från databasen.