Tipo errato
LocalDateTime
è il tipo sbagliato qui. Quella classe non può rappresentare un momento, come spiegato nel suo Javadoc.
Quella classe di proposito non ha il concetto di fuso orario o offset dall'UTC. Quindi rappresenta una data e un'ora del giorno come "mezzogiorno del 23 gennaio 2019", ma non so se è mezzogiorno a Tokyo, Parigi o Montréal, per esempio, tre momenti molto diversi che sono diverse ore di distanza. Quindi questo tipo è appropriato per il tipo SQL standard TIMESTAMP WITHOUT TIME ZONE
– senza , non con .
Per ulteriori discussioni, vedere:Qual è la differenza tra Instant e LocalDateTime?
Tipo destro
Per SQL standard, digitare TIMESTAMP WITH TIME ZONE
, dovresti usare i tipi Java Instant
, OffsetDateTime
o ZonedDateTime
. Di questi tre, JDBC 4.2 richiede il supporto solo per il secondo, OffsetDateTime
.
Recupero.
OffsetDateTime odt = myResultSet.getObject( … , OffsetDateTime.class ) ;
Il valore recuperato da Postgres sarà sempre in UTC. Lo standard SQL non specifica questo comportamento, quindi i database variano. In Postgres qualsiasi valore inviato a un campo di tipo TIMESTAMP WITH TIME ZONE
è regolato in UTC. I valori recuperati sono in UTC.
Memorizzazione.
myPreparedStatement.setObject( … , odt ) ;
Regola da UTC (offset di zero) all'ora dell'orologio da parete utilizzata dalle persone di una particolare regione (un fuso orario).
ZoneId z = ZoneId.of( "Asia/Tokyo" ;
ZonedDateTime zdt = odt.atZoneSameInstant( z ) ;
APP
Non uso JPA, preferisco mantenere le cose semplici.
Ma secondo questa risposta , JPA 2.2 supporta java.time tipi.
Anche Hibernate supporta java.time .