Falscher Typ
LocalDateTime ist hier der falsche Typ. Diese Klasse kann keinen Moment darstellen, wie in ihrem Javadoc erklärt.
Diese Klasse hat absichtlich kein Konzept der Zeitzone oder des Offsets von UTC. Es repräsentiert also ein Datum und eine Uhrzeit wie „Mittag am 23. Januar 2019“, aber ich weiß nicht, ob das zum Beispiel Mittag in Tokio, Paris oder Montréal ist, drei sehr unterschiedliche Momente liegen mehrere Stunden auseinander. Daher ist dieser Typ für den Standard-SQL-Typ TIMESTAMP WITHOUT TIME ZONE geeignet – ohne , nicht mit .
Weitere Informationen finden Sie unter:Was ist der Unterschied zwischen Instant und LocalDateTime?
Richtiger Typ
Geben Sie für Standard-SQL TIMESTAMP WITH TIME ZONE ein , sollten Sie die Java-Typen Instant verwenden , OffsetDateTime , oder ZonedDateTime . Von diesen dreien benötigt JDBC 4.2 nur Unterstützung für den zweiten, OffsetDateTime .
Abruf.
OffsetDateTime odt = myResultSet.getObject( … , OffsetDateTime.class ) ;
Der von Postgres abgerufene Wert ist immer in UTC. Der SQL-Standard spezifiziert dieses Verhalten nicht, daher variieren Datenbanken. In Postgres wird jeder Wert an ein Feld vom Typ TIMESTAMP WITH TIME ZONE gesendet wird in UTC angepasst. Abgerufene Werte sind in UTC.
Speicherung.
myPreparedStatement.setObject( … , odt ) ;
Anpassung von UTC (Offset von Null) an die von den Menschen einer bestimmten Region (einer Zeitzone) verwendete Uhrzeit.
ZoneId z = ZoneId.of( "Asia/Tokyo" ;
ZonedDateTime zdt = odt.atZoneSameInstant( z ) ;
JPA
Ich verwende JPA nicht, da ich es vorziehe, die Dinge einfach zu halten.
Aber laut dieser Antwort , JPA 2.2 unterstützen die java.time Typen.
Auch Hibernate unterstützt java.time .
