Eu finalmente fiz esse "trabalho" - de uma maneira meio hackeada - desativando a validação do esquema.
Anteriormente, eu tinha
<property name="hibernate.hbm2ddl.auto" value="validate"/>"hibernate.hbm2ddl.auto"
no meu persistence.xml. Quando eu comentei essa propriedade, meu servidor de aplicativos foi iniciado e o modelo "funcionou". A forma final da minha entidade foi:
@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 */
Depois de ler bastante sobre isso, fiquei com a impressão de que não há uma maneira fácil de mapear o carimbo de data/hora do Postgresql com colunas de fuso horário.
Algumas combinações de implementação + banco de dados JPA suportam isso nativamente ( EclipseLink + Oracle é um exemplo ). Para hibernar, com extensões jodatime, é possível armazenar timestamps com reconhecimento de fuso horário usando um timestamp normal + um campo varchar para o fuso horário (não pude fazer isso porque estava impedido de alterar o esquema do banco de dados). Tipos de usuário Jadira ou tipos de usuário completamente personalizados também podem ser usados para resolver esse problema.
Preciso observar que meu caso de uso para essa entidade é "somente leitura", para que eu possa me safar com uma "solução" aparentemente ingênua.