Mauvais type
LocalDateTime est le mauvais type ici. Cette classe ne peut pas représenter un moment, comme expliqué dans son Javadoc.
Cette classe n'a délibérément aucun concept de fuseau horaire ou de décalage par rapport à UTC. Donc ça représente une date et une heure du jour comme « midi le 23 janvier 2019 », mais je ne sais pas si c'est midi à Tokyo, Paris ou Montréal par exemple, trois moments très différents qui sont à plusieurs heures d'intervalle. Ce type est donc approprié pour le type SQL standard TIMESTAMP WITHOUT TIME ZONE – sans , pas avec .
Pour plus de discussion, voir :Quelle est la différence entre Instant et LocalDateTime ?
Type droit
Pour le type SQL standard TIMESTAMP WITH TIME ZONE , vous devez utiliser les types Java Instant , OffsetDateTime , ou ZonedDateTime . De ces trois, JDBC 4.2 ne nécessite la prise en charge que du second, OffsetDateTime .
Récupération.
OffsetDateTime odt = myResultSet.getObject( … , OffsetDateTime.class ) ;
La valeur récupérée de Postgres sera toujours en UTC. La norme SQL ne spécifie pas ce comportement, les bases de données varient donc. Dans Postgres, toute valeur envoyée à un champ de type TIMESTAMP WITH TIME ZONE est ajusté en UTC. Les valeurs récupérées sont en UTC.
Stockage.
myPreparedStatement.setObject( … , odt ) ;
Ajustez de l'UTC (décalage de zéro) à l'heure de l'horloge murale utilisée par les habitants d'une région particulière (un fuseau horaire).
ZoneId z = ZoneId.of( "Asia/Tokyo" ;
ZonedDateTime zdt = odt.atZoneSameInstant( z ) ;
APP
Je n'utilise pas JPA, préférant garder les choses simples.
Mais selon cette réponse , JPA 2.2 prend en charge java.time type.
Hibernate prend également en charge java.time .
