Проблема с датой в весенней загрузке данных

У меня проблема с отдыхом данных spring, когда я обрабатываю даты. Вкратце, это перенос даты на один день. Например, если у меня есть 1111-11-11, он возвращает мне 1111-11-10.

Здесь в SO есть несколько связанных сообщений (ex1, ex2, ex3 ), но ни один из них не решил проблему.

У меня есть объект с этим LocalDate:

@Column(nullable=true)
private LocalDate birthDate;

У меня также есть этот репозиторий:

@RepositoryRestResource(collectionResourceRel = "person", path = "person")
public interface PersonRepository extends PagingAndSortingRepository<Person, Long>{

}

Когда я сохраняю birthDate в базе данных (я использую MySQL), он сохраняется правильно. Однако, когда я делаю этот запрос, например:

Person p = personRepo.findById(1L).get();

Дата выбирается с опозданием на один день (как в примере выше). Я попытался реализовать это предложение, то есть изменить LocalDate to Date и включить аннотацию Джексона, но это не работает. Я тоже пытался включить jackson-modules-java8, но проблема осталась.

Теперь самое интригующее. Поскольку я просто тестировал, я включил дату 1111-11-11. Я изменил это на сегодняшнюю дату 2019-02-06. Тогда выборка работает! В это время, я думаю, если это была проблема с очень старыми датами. Таким образом, я попробовал, например, 1970-01-01, а весной вернулся 1969-12-31. Я понял, что если я включаю в базу данных даты выше 1986-01-01, все работает нормально. Однако, если я включу что-нибудь ниже этого, я получу дату на один день позже.

Есть ли у кого-нибудь намек на эту проблему?

Спасибо за ваше время!

EDIT: я также проверил часовой пояс моей базы данных, и все в порядке!

+--------------------+---------------------+--------------------+
| @@GLOBAL.time_zone | @@session.time_zone | @@system_time_zone |
+--------------------+---------------------+--------------------+
| SYSTEM             | SYSTEM              | -02                |
+--------------------+---------------------+--------------------+
1 row in set (0,00 sec)

person André Pacheco    schedule 06.02.2019    source источник
comment
сри (когда мне не очевидно, но), 1111 г. н.э. или что-то другое....?   -  person xerx593    schedule 06.02.2019
comment
Эта дата просто пример, но это было до нашей эры (смеется)   -  person André Pacheco    schedule 06.02.2019
comment
Ну, я нашел несколько похожих вопросов, но ни один из них не решил этот случай! знак равно   -  person André Pacheco    schedule 06.02.2019
comment
Может проблема с часовым поясом? Например, если вы выберете 2019-02-06T00:00 в зоне +0, это будет равно 2019-02-05T23:00 в зоне +1, и у вас будет 2019-02-05 вместо 2019-02-06, а временная метка действительно верный.   -  person ILya Cyclone    schedule 06.02.2019
comment
год (1986) позволяет мне предположить: это как-то связано с переходом на летнее время (-> политика)   -  person xerx593    schedule 06.02.2019
comment
@ILyaCyclone, это было первое, что я подумал. А как же 1986/1986 годы? Просто бывает года до 1986. После этого все работает отлично!   -  person André Pacheco    schedule 06.02.2019
comment
@ILyaCyclone и, насколько я знаю, у LocalDate не должно быть проблем с часовым поясом! Он должен быть независимым.   -  person André Pacheco    schedule 06.02.2019
comment
В основном правильно, LocalDate не должно быть проблем с часовым поясом. Но иногда некоторые преобразования в поиске все равно вносят некоторые изменения. Каков тип данных вашего столбца базы данных в MySQL? А вы в каком часовом поясе?   -  person Ole V.V.    schedule 06.02.2019
comment
@ОлеВ.В. тип данных в базе данных date, и я нахожусь в Бразилии, в настоящее время это UTC -2 из-за летнего времени   -  person André Pacheco    schedule 07.02.2019


Ответы (2)


Наконец, я нашел решение. После того, как @ILyaCyclone и @OleV.V. комментарии, я начал искать информацию о часовом поясе, весенней загрузке и LocalDate. Действительно, LocalDate не несет информации UTC. Однако, когда я извлекаю эти данные из базы данных, JVM необходимо выполнить преобразование, чтобы SQL date стал LocalDate.

Поэтому первое, что я сделал, это проверил часовой пояс базы данных:

SELECT TIMEDIFF(NOW(), UTC_TIMESTAMP) as GMT_TIME_DIFF;

который вернулся:

+--------------------+---------------------+--------------------+
| @@GLOBAL.time_zone | @@session.time_zone | @@system_time_zone |
+--------------------+---------------------+--------------------+
| SYSTEM             | SYSTEM              | -02                |
+--------------------+---------------------+--------------------+

и:

SELECT TIMEDIFF(NOW(), UTC_TIMESTAMP)

возвращение:

+--------------------------------+
| TIMEDIFF(NOW(), UTC_TIMESTAMP) |
+--------------------------------+
| -02:00:00                      |
+--------------------------------+

Все эти ответы SQL были в порядке. Итак, проблема была в весеннем ботинке. Что решило проблему, так это установить UTC в коде. Я нашел эту подсказку здесь< /а>.

@PostConstruct
void started() {
    TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
}

После этого все даты стали работать исправно.

Решается проблема. Однако я понятия не имею о дате после и до 1986 года. Если у кого-то есть подсказка, пожалуйста, поделитесь со мной.

Спасибо, ребята, которые приложили усилия, чтобы помочь мне. Я правда ценю это.

person André Pacheco    schedule 07.02.2019
comment
Спасибо за ответ на свой вопрос, это здорово. Деталь, я считаю, что рекомендуемый способ установить часовой пояс по умолчанию - через -Duser.timezone=Etc/UTC в командной строке Java. - person Ole V.V.; 07.02.2019
comment
Я обнаружил, что вы также можете добавить в applications.property эти строки: spring.jackson.date-format=yyyy-MM-dd и spring.jackson.time-zone=Brazil/East Вкратце, это касается проблем с часовыми поясами. Но я не знаю, почему Java получает это от LocalDate. Когда я это выясню, я хочу обновить этот ответ. - person André Pacheco; 07.02.2019

Используйте зависимость https://mvnrepository.com/artifact/com.fasterxml.jackson.datatype/jackson-datatype-hibernate5

Например, если вы используете Gradle

implementation ('com.fasterxml.jackson.datatype:jackson-datatype-hibernate5:2.9.8')
person Do Nhu Vy    schedule 06.02.2019
comment
Спасибо за ваш ответ, однако, это не сработало. Я все еще получаю дату с задержкой на один день, если дата до 1985 года. Если она после 1985 года, она работает нормально! - person André Pacheco; 07.02.2019