title: jooq UTC localdatetime changes between save and load
body: <p>My coworker created a postgresql database using jooq. Since then, we created objects with fields and the value of LocalDateTime.now(ZoneOffset.UTC). When those get saved to this database and read again later a few hours changed in our data object:</p>
  <pre><code>public class PlannedInvoice
  {
      private UUID accountId;
      private LocalDateTime billingTime;
  }
  </code></pre>
  <p>The save method looks similar to this:</p>
  <pre><code>LocalDateTime now = LocalDateTime.now(ZoneOffset.UTC);
  UUID accountId = UUID.randomUUID();
  
  PlannedinvoiceRecord record = plannedInvoiceService.create();
  record.setAccountid(accountId.toString());
  record.setBillingtime(now.atOffset(ZoneOffset.UTC));
  record.store();
  </code></pre>
  <p>And the read method like this:</p>
  <pre><code>return dsl.selectFrom(PLANNEDINVOICE)
          .where(PLANNEDINVOICE.ACCOUNTID.eq(accountId.toString()))
          .fetchOneInto(PlannedInvoice.class);
  </code></pre>
  <p>The database uses <code>timestamp with time zone</code> currently, but I would also be happy to replace it with actual LocalDateTime to avoid these problems altogether(<a href="https://www.jooq.org/doc/3.13/manual/code-generation/codegen-advanced/codegen-config-generate/codegen-generate-java-time-types/" rel="nofollow noreferrer">JOOQ supports this</a>)!</p>
  <p>When we save a value of <code>LocalDateTime.of(2020, Month.AUGUST, 13, 0, 0)</code>, it will be <code>2020-08-12 20:00:00-04</code> in the database. This still seems correct.</p>
  <p>Reading the value from the database seems where things go wrong. After the read method the value of billingTime is 2020-08-12 20:00:00. It seems to me like the time zone gets ignored by <code>fetchOneInto</code> when reconstructing the data object.</p>
  <p>So why is there a conversion when saving UTC values and why is there no conversion when reading those back from the database? This seems very counterintuitive to me. I would prefer to avoid any time zone conversions at all.</p>