Я добавлю это как отдельный ответ, так как это - по-моему, важная информация для любого обновляющего для Спящего режима 4, и нуждающийся в миграции на использование персистентных временных типов jadira. Эта страница высоко оценивается в результатах поиска Google для, в спящем режиме 4 и jodatime, таким образом, я добавлю его здесь. (Для отдельного обсуждения этой проблемы см.: время Joda DateTime неправильно хранит в базе данных )

, Если Вы находитесь в часовом поясе кроме UTC, важная часть конфигурации необходима для получения того же поведения, как Вы были бы с joda-разовым быть-в-спящем-режиме-типом-поддержки. Путем временные типы jadira работа по умолчанию, посредством преобразования всех значений к часовому поясу UTC прежде, чем сохраниться к базе данных и преобразовать назад в часовой пояс системы при загрузке значений из базы данных.

я был записан этим после обновления, когда у меня было много меток времени с моим точным часовым поясом в базе данных (UTC+1 (+2 когда летний период)). При загрузке после обновления для Спящего режима 4, 1 или 2 часа (в зависимости от того, была ли метка времени в летнее время), был добавлен к значению в базе данных, которая означала, что все существующие метки времени были представлены ошибочно. Далее, новые значения метки времени были сохранены в базе данных с часовым поясом UTC, ведя их для появления правильно в приложении, но неправильно в базе данных. В целом, горячая путаница часовых поясов и меток времени.

Так, для получения того же поведения как с быть-в-спящем-режиме-поддержкой joda-времен (дата и время, сохраняемая, будучи часового пояса рассматриваемого сервера, и метки времени в базе данных, совпадающей с, что загружается в приложение), следующие свойства должны быть добавлены к конфигурации JPA/Hibernate (в моем случае, hibernate.properties):

jadira.usertype.autoRegisterUserTypes=true
jadira.usertype.databaseZone=jvm
jadira.usertype.javaZone=jvm

Это удостоверится, что метки времени в базе данных будут иметь тот же часовой пояс как база данных приложения, которое в свою очередь будет часовым поясом jvm (в большинстве случаев часы сервера приложений).

кроме того, от того, что я понимаю, autoRegisterUserTypes - свойство устраняет необходимость @Type - аннотация для выбора общих типов среди них Jodatime-типы DateTime и LocalDate.