Я вижу преимущества в том, что почти все
Интерфейсы, использующие LocalDateTime (в
уровень сервиса как минимум) так что мой
Приложение не должно управлять
Часовые пояса и можно смело предполагать время всегда в UTC.
Я не уверен, что понимаю ваше мышление здесь. LocalDateTime и DateTime представляют два совершенно разных понятия. Это не тот случай, когда LocalDateTime имеет неявный часовой пояс UTC: на самом деле он имеет нет часового пояса (внутренне он может быть представлен как DateTime с часовым поясом UTC, но это просто деталь реализации, он делает не имеет значения для программиста, который его использует).
Вы можете увидеть в документах API , что, в то время как DateTime является "Instant" (точка на мировой временной шкале) , физическая концепция), LocalDateTime НЕ такая вещь. LocalDateTime на самом деле Partial («гражданская» концепция) в другой иерархии классов. Имена классов, к сожалению, могут заставить вас думать, что LocalDateTime - это какая-то специализация DateTime: ну, это не так.
A LocalDateTime следует рассматривать как пару {Date (Y/M/D); Time (hh:mm:ss.msec)}, набор чисел, который соответствует «гражданскому» стандартному представлению связанных со временем данных. Если нам дано LocalDateTime, мы не можем преобразовать его непосредственно в DateTime, нам нужно указать часовой пояс; и это обращение приводит нас к другому виду сущности. (Аналогия: строки и байтовые потоки в Java: для преобразования между ними необходимо указать кодировку charset, потому что это концептуально разные вещи)
Когда использовать один или другой в приложении ... это иногда спорно, но часто достаточно ясно, когда понятия Jodatime понятны. И ИМО не имеет большого отношения к «слоям», возможно, больше к случаям использования или сценариям.
Нетривиальный пример: вы работаете в Google, программируете Календарь. Вы должны позволить пользователю управлять (добавлять, видеть, изменять) событием, которое включает дату и время (позволяет игнорировать повторяющиеся события), например: « У меня назначена встреча с моим врачом 2019-июля-3 в 10:00 ч ». Какую сущность даты-времени использовать на программном уровне (для этот сценарий использования )? Я бы сказал: LocalDateTime. Потому что пользователь на самом деле имеет дело не с физическим моментом времени, а с гражданским временем: датой и временем, которые показывают часы на его запястье или в его доме. Он даже не думает о часовых поясах (давайте проигнорируем особый случай пользователя, который путешествует по всему миру ...) Затем, на уровне бизнеса и представления, LocalDateTime кажется правильным объектом.
Но предположим, что вы должны также написать другой сценарий: напоминание. Когда внутренний планировщик Google обнаруживает, что событие, сохраненное пользователем, будет через N минут в будущем, он должен отправить ему напоминание. Здесь « N минут» - это полностью «физическая» концепция времени, поэтому здесь «бизнес-уровень» будет иметь дело с DateTime. Есть несколько альтернатив, например: событие было сохранено в БД как LocalDateTime (т. Е. Просто время и дата без часового пояса - для представления этого часто используется временная метка UTC, но это деталь реализации). В этом сценарии (только в этом) мы должны загрузить его как DateTime, мы конвертируем его, используя часовой пояс, вероятно, из профиля пользователя.