Descobri recentemente que, dependendo do driver de banco de dados usado, o jOOQ pode apresentar algum comportamento estranho na análise de DateTime. jOOQ retorna data e hora de deslocamento como Z (UTC), embora não seja
Especificamente, no meu caso, usar um driver Postgres diferente resultou em DefaultBinding.java recebendo um objeto de calendário que tem um carimbo de data/hora, mas chamando toString nele para analisar. Acontece que toString não imprime o fuso horário, então o jOOQ inferiu que estava na hora local.
Para mim, as linhas ofensivas em DefaultBinding.java (eu estava usando um timestamp com fuso horário) foram:
else if (type == OffsetDateTime.class) {
result = (T) offsetDateTime(ctx.resultSet().getString(ctx.index()));
}
Você pode estar em uma linha diferente nessa série de outros ifs com base em não ter um fuso horário.
Em meus testes, também descobri que alterar o horário do sistema alterava o resultado, mas alterar o horário da sessão não fazia nada.
Felizmente para mim, uma mudança para o driver padrão do Postgres resolveu o problema. Se não, eu iria olhar para sobrecarregar a ligação para OffsetDateTime para corrigir o uso de toString e sua remoção associada do fuso horário relevante. Você pode precisar seguir esse caminho, infelizmente, a menos que também esteja usando um driver SQL que possa ser atualizado ou substituído. Ou você pode armazená-lo com um fuso horário e depois converter para o fuso horário desejado ao carregar do banco de dados.
