Joda-разовый: DateTime, DateMidnight и использование LocalDate

Я вижу преимущества в том, что почти все интерфейсы используют LocalDateTime (по крайней мере на уровне обслуживания), так что мой Приложение не обязано управлять часовыми поясами и может безопасно принимать время всегда в формате UTC.

Я не уверен, что понимаю ваш образ мыслей. LocalDateTime и DateTime представляют две совершенно разные концепции.Дело не в том, что LocalDateTime имеет неявный часовой пояс UTC: на самом деле он не имеет часового пояса без (внутренне он может быть представлен как DateTime с часовым поясом UTC, но это просто деталь реализации, программисту не важно, кто ее использует).

В документации API можно увидеть, что, хотя DateTime является « Instant » (точка на мировой шкале времени, физическая концепция), LocalDateTime НЕ ТАКОЕ. LocalDateTime на самом деле является частичным («гражданская» концепция) в другой иерархии классов. Названия классов могут, к сожалению, заставить вас думать, что LocalDateTime является некоторой специализацией DateTime : ну, это не так.

A LocalDateTime следует рассматривать как пару { Date ( Y / M / D ); Время ( чч: мм: сс.мсек )}, набор чисел, который соответствует «гражданскому» стандартному представлению данных, связанных со временем. Если нам задано LocalDateTime , мы не сможем напрямую преобразовать его в DateTime , нам нужно указать часовой пояс; и это преобразование приводит нас к другому виду сущностей. (Аналогия: строки и потоки байтов в Java: для преобразования между ними необходимо указать кодировку кодировки, потому что они концептуально разные вещи)

Когда использовать то или другое в приложении ... это иногда спорно, но часто становится достаточно ясным, если понимать концепции Jodatime.И IMO не имеет большого отношения к «слоям», возможно, больше к вариантам использования или сценариям.

Нетривиальный пример с границами: вы работаете в Google, программируете Календарь. Вы должны позволить пользователю управлять (добавлять, видеть, изменять) событие, которое включает дату и время (позволяет игнорировать повторяющиеся события), например: « У меня назначена встреча с моим врачом на 3 июля 2019 года в 10:00. am ". Какой объект времени и даты следует использовать на уровне программного обеспечения (для этот вариант использования )? Я бы сказал: a LocalDateTime . Потому что пользователь на самом деле имеет дело не с физическим моментом времени, а с гражданским временем: датой и временем, которые отображают часы на его запястье или в его доме. Он даже не думает о часовых поясах (давайте проигнорируем особый случай пользователя, который путешествует по миру ...) Тогда на уровне бизнеса и представления LocalDateTime кажется правильным объектом.

Но предположим, что вы также должны написать другой сценарий: напоминание. Когда внутренний планировщик Google обнаруживает, что событие, сохраненное пользователем, наступит через N минут, он должен отправить ему напоминание. Здесь « N минут через » - это полностью «физическое» понятие времени, поэтому здесь «бизнес-уровень» будет иметь дело с DateTime . Есть несколько альтернатив, например: событие было сохранено в БД как LocalDateTime (т.е. просто время и дата без часового пояса - часто для этого используется временная метка UTC, но это деталь реализации) .В этом сценарии (только в этом) мы должны загрузить его как DateTime , мы конвертируем его, используя часовой пояс, вероятно, из профиля пользователя.