Использование localDate с UTC - PullRequest
Новая
       50

Использование localDate с UTC

0 голосов
/ 08 июля 2019

Я столкнулся с проблемой использования LocalDate в UTC. Мой сервер использует UTC, а моя база данных использует UTC. Я использовал LocalDate для хранения billingDate для приложения на основе подписки.

Что происходит, мы выставляем счета в полночь по Гринвичу (при выполнении сравнений, таких как billingDate <= LocalDate.now ()). На самом деле мы хотим выставить счет после полуночи по тихоокеанскому времени. </p>

Я действительно чувствовал, что использование LocalDate было бы уместным здесь, потому что мы просто хотим выставить счет в какой-то момент в течение этого дня. Тем не менее, это не кажется практичным при выполнении сравнений непосредственно в коде или в базе данных (billing_date <= CURRENT_DATE ()). Я сделал ошибку, это должно быть ZonedDateTime в PST? Или мы должны конвертировать в ZonedDateTime для сравнения? Он склонен к ошибкам, нам нужно помнить, чтобы преобразовывать каждый раз, когда мы проводим сравнение, но, возможно, это правильное решение? </p>

Кто-нибудь имел опыт работы с этой ситуацией и нашел хорошее решение?

Я посмотрел на этот вопрос, но он не отвечает на мой вопрос: Spring REST LocalDate UTC отличается от одного дня

Ответы [ 2 ]

1 голос
/ 08 июля 2019

Я полагаю, что это всего лишь вопрос передачи желаемого часового пояса в LocalDate.now(ZoneId).

  • Используйте LocalDate.now(ZoneId.of("Asia/Manila")) для стандартного филиппинского времени.На данный момент он дает 2019-07-09.
  • Используйте LocalDate.now(ZoneId.of("Pacific/Pitcairn")) для стандартного времени на Питкэрне.Это просто дало 2019-07-08.

Я предполагаю, что вы не имели в виду тихоокеанское стандартное время, поскольку ни один часовой пояс не использует тихоокеанское стандартное время, как мы говорим (те, что зимой, включеныТихоокеанское летнее время сейчас).В любом случае, учтите, что трехбуквенные сокращения часовых поясов часто неоднозначны.

Классы java.time, имеющие метод now, обычно имеют три перегруженных варианта:

  1. Тот, который принимает ZoneId аргументы, которые я рекомендую для общего использования.
  2. Тот, который принимает Clock аргумент, который отлично подходит для тестируемости.Clock включает в себя часовой пояс, поэтому этот также возвращает текущую дату и / или время в указанном часовом поясе.
  3. Тот, который не принимает никаких аргументов и использует часовой пояс JVM по умолчанию.Я рекомендую вам никогда не использовать его.Читателю приятно знать, что вы рассмотрели часовой пояс и выбрали тот, который вам нужен.И часовой пояс по умолчанию может быть изменен в любое время любой программой, работающей в той же JVM, поэтому он недостаточно стабилен, чтобы полагаться на реальную работу.
0 голосов
/ 08 июля 2019

Я чувствую, что вы должны использовать Instant s.

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

Ну нет. Вы действительно заботитесь о времени, которое вы выставляете, потому что ваша база данных заботится о времени. Время выставления счета хранится как 00:00 UTC. Поскольку это момент времени, я думаю, что Instant будет наиболее подходящим выбором здесь. Вы также можете использовать ZonedDateTime, но, учитывая, что вы, вероятно, получаете java.sql.Date из своей базы данных, в которой уже есть метод toInstant, использование Instant s более удобно.

Вы можете получить мгновение из года, месяца, дня следующим образом: 

LocalDate ld = LocalDate.of(2019, 7, 8);
Instant i = ld.atStartOfDay(ZoneId.of("America/Los_Angeles")).toInstant();

America/Los_Angeles является PST.

...