Как сгенерировать java.sql.Timestamp в UTC для сравнения запросов? - PullRequest
0 голосов
/ 26 июня 2019

В настоящее время я создаю шлюз с использованием Spring-Boot, который считывает данные из базы данных PSQL. База данных PSQL v11.3 заполняется веб-приложением Rails, на котором работает Rails 5.1.3. Приложение Spring использует Java 8 и Spring Data JPA.

Соответствующий запрос запускается запланированным методом в приложении Spring, которое сравнивает текущее время с updated_at разами таблицы. Запрос выглядит следующим образом:

@Query("SELECT d from SimulatedDeviceEntity d WHERE d.updatedAt > :currentTime")
List<SimulatedDeviceEntity> findByLastUpdated(@Param("currentTime") Timestamp currentTime);

Если я получу SimulatedDeviceEntity из этого запроса и получу его время из getUpdatedAt, это будет тип java.sql.Timestamp. При отображении с помощью toString() я получаю 2019-06-26 17:24:20.034923 для устройства, которое было обновлено по моему местному времени в 13:24.

Я пробовал разные ответы о том, как сгенерировать метку времени в UTC, включая здесь , где мой код для создания метки времени -

LocalDateTime ldt = LocalDateTime.now();
ZonedDateTime zdt = ZonedDateTime.of(ldt, ZoneId.of("GMT"));
Timestamp currentTime = Timestamp.valueOf(zdt.toLocalDateTime());

Независимо от того, что я пытаюсь сделать, вызов toString для любого из них сгенерирует метку времени в моем местном времени, которое на 4 часа отстает от UTC. Я понял, что это намеренно, однако при вызове toString на метках времени, полученных из приложения Rails, даже тогда, когда они отображаются в UTC. Учитывая, что toString должен отображать метку времени по местному времени, тот факт, что она отображается для моих last_updated раз в UTC, заставляет меня поверить, что здесь происходит что-то еще.

1 Ответ

0 голосов
/ 26 июня 2019

На самом деле, когда вы сравниваете две метки времени, вам не нужно конвертировать их в один и тот же часовой пояс. Это достаточно умно, чтобы сравнить их как абсолютные времена. Что он делает, он преобразует любое значение Timestamp в Long значение в миллисекундах, которое прошло с 1.1.1970 00:00 UTC, а затем сравнивает их. Таким образом, вам, вероятно, не нужно конвертировать свое время. должно работать как есть.

...