jodatime et veille prolongée des changements de soutien de fuseau horaire

Question

j'ai une entité persistante avec un champ LocalTime mis en correspondance avec une colonne time without time zone dans une table de postgre, je renseigner ce champ dans mon application comme ceci:

int hour = 10 
int minutes = 12 
MyEntity e = new MyEntity() 
e.setTime(new LocalTime(hour, minutes)); 

alors je persiste l'entité sur la base de données en utilisant hibernate, plus tard dans l'application je récupère l'entité et affiche le champ de temps, il montre correctement 10:12 mais quand je vois la valeur sur la table (en utilisant pg-admin), il montre: 04:12 quand il devrait être 10:12, le fuseau horaire dans mon jvm et dans mon sistem est CST (qui est UTC-6) il me semble que quelque part soit dans hibernate ou jodatime mon champ de temps est commencer converti à mon fuseau horaire à la fois lors de l'insertion à la base de données et lors de la récupération des valeurs, im i? est-il un moyen d'empêcher cette behaivor ?, im en utilisant jre 1.6.0_22, mise en veille prolongée 3, Joda temps 1.5.1 et Joda-temps mise en veille prolongée 1.2

modifier: oublié de mentionner que le champ est mis en correspondance en veille prolongée avec:

type="org.joda.time.contrib.hibernate.PersistentLocalTimeAsTime" 

Answer 1

Eh bien, il peut être à jour, mais les docs pour une classe appelée PersistentLocalTime dire ceci:

persist LocalTime via Hibernate comme TIME de données SQL - noter que sous -secondes valeurs ne seront pas re taché. Ce type est fondamentalement compatible avec org.joda.time.contrib.hibernate.PersistentLocalTimeAsTime. Cependant, notez que org.joda.time.contrib.hibernate.PersistentLocalTimeAsTime contient un bogue où les temps écrits seront décalés par rapport à GMT en raison de l'utilisation de Time.setTime (long). Cette classe n'est pas affectée par ce problème, mais cela signifie que vous ne pouvez pas vous fier à l'interprétation de ce type pour être la même pour les deux classes.

(moi qui souligne.)

On dirait que vous êtes en cours d'exécution dans ce problème, mais que l'utilisation PersistentLocalTime serait plutôt le fixer.