W końcu udało mi się to "zadziałać" - w hackowy sposób - wyłączając walidację schematu.
Wcześniej miałem <property name="hibernate.hbm2ddl.auto" value="validate"/>"hibernate.hbm2ddl.auto"
w moim persistence.xml. Kiedy zakomentowałem tę właściwość, mój serwer aplikacji uruchomił się i model "działał".
Ostateczna forma mojej jednostki to:
@Entity
@Table(schema = "content", name = "theme")
public class Theme extends AbstractBaseEntity {
private static final long serialVersionUID = 1L;
@Column(name = "run_from", columnDefinition = "timestamp with time zone not null")
@NotNull
@Temporal(TemporalType.TIMESTAMP)
private Date runFrom;
@Column(name = "run_to", columnDefinition = "timestampt with time zone not null")
@NotNull
@Temporal(TemporalType.TIMESTAMP)
private Date runTo;
/* Getters, setters, .hashCode(), .equals() etc omitted */
Po przeczytaniu sporej części tego odniosłem wrażenie, że nie ma łatwego sposobu na zmapowanie znacznika czasu Postgresql z kolumnami stref czasowych.
Niektóre kombinacje implementacji JPA + bazy danych obsługują to natywnie ( EclipseLink + Oracle jest jednym z przykładów ). W przypadku hibernacji, z rozszerzeniami jodatime, możliwe jest przechowywanie znaczników czasu uwzględniających strefę czasową przy użyciu normalnego znacznika czasu + pola varchar dla strefy czasowej (nie mogłem tego zrobić, ponieważ byłem ograniczony do zmiany schematu bazy danych). Typy użytkowników Jadira lub całkowicie niestandardowe typy użytkowników mogą być również użyte do rozwiązania tego problemu.
Muszę zauważyć, że mój przypadek użycia dla tej encji to „tylko do odczytu”, więc mogłem uciec z pozornie naiwnym „rozwiązaniem”.