Ik heb dit uiteindelijk laten "werken" - op een hackachtige manier - door schemavalidatie uit te schakelen.
Voorheen had ik <property name="hibernate.hbm2ddl.auto" value="validate"/>"hibernate.hbm2ddl.auto"
in mijn persistentie.xml. Toen ik commentaar gaf op deze eigenschap, begon mijn app-server en het model "werkte".
De uiteindelijke vorm van mijn entiteit was:
@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 */
Nadat ik hier nogal wat over had gelezen, kreeg ik de indruk dat er geen gemakkelijke manier is om Postgresql-tijdstempels in kaart te brengen met tijdzonekolommen.
Sommige combinaties van JPA-implementatie + database ondersteunen dit native (EclipseLink + Oracle is een voorbeeld). Voor slaapstand, met jodatime-extensies, is het mogelijk om tijdzone-bewuste tijdstempels op te slaan met behulp van een normale tijdstempel + een varchar-veld voor de tijdzone (ik kon dat niet doen omdat ik beperkt was in het wijzigen van het databaseschema). Jadira-gebruikerstypen of volledig aangepaste gebruikerstypen kunnen ook worden gebruikt om dit probleem aan te pakken.
Ik moet opmerken dat mijn use-case voor deze entiteit "alleen-lezen" is, dus ik zou weg kunnen komen met een schijnbaar naïeve "oplossing".