Я схожу с ума здесь ... Недавно я заметил, что время неправильно отображается в моих объектах, управляемых JPA, когда я получаю доступ к полю Date:
- Мой личный часовой поясимеет значение CEST, то же самое для машины, на которой работают Glassfish и MySQL.
- Glassfish получает указание использовать UTC в качестве часового пояса по умолчанию:
@Startup -bean устанавливает TimeZone.setDefault(TimeZone.getTimeZone("UTC")); - Кэширование в постоянном режиме отключено.xml
Вот что происходит:
- У объекта A есть поле
syncTimestamp из java.util.Date. - Когда запускается определенный ресурс REST.отметка времени установлена на:
a.setSyncTimestamp(new Date()).Давайте предположим, что мои часы на стене показывают 14: 30: 00h (для краткости дата опущена). - Объект управляется, поэтому обновление заканчивается в БД.Строка в базе данных (типа
DATETIME) показывает ожидаемое значение «12: 30: 00h» - CEST в настоящее время на 2 часа опережает UTC. - Доступ к получателю в той же транзакции выводит метку времени как «12: 30: 00.123Z "(обратите внимание на миллисекунды).
- При доступе к геттеру в отдельной транзакции после повторного извлечения объекта из базы данных (отключенное кэширование) выдается" 10: 30: 00Z ".
Таким образом, при загрузке сущности из БД это выглядит как JPA, преобразованный снова из того, что он считает меткой времени CEST в UTC, вычитая 2 часа.
Я прочитал много постово JPA, часовом поясе и т. д. Я узнал следующее: ни java.util.Date, ни MySQL DATETIME не имеют представления о часовых поясах.Это не должно быть проблемой, если все всегда считается "UTC", верно?Теперь почему JPA (я думаю?) Конвертирует значение?
(PS: я нашел сообщение , относящееся к . Он предлагает поместить JVM в часовой пояс UTC -- но разве это не то, что делает мой Startup Bean?)
РЕДАКТИРОВАТЬ : Оказывается, что пропал важный бит информации.Чтобы подготовиться к кластеризации Glassfish, я переместил базу данных для службы таймера EJB в мою базу данных MySQL.В результате драйвер JDBC был извлечен из приложения в lib-каталог glassfish.