Ответ 1
Я вижу преимущества наличия почти всех Интерфейсы, использующие LocalDateTime (at уровень обслуживания по крайней мере), чтобы мой Приложению не нужно управлять Временные часовые пояса и могут спокойно использовать Times всегда в формате UTC.
Я не уверен, что я понимаю вашу мысль. LocalDateTime и DateTime представляют два совершенно разных понятия. Это не тот случай, когда a 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: для преобразования между ними вы должны указать кодировку кодировки, потому что они концептуально разные вещи)
Если использовать одну или другую сторону в приложении... иногда обоснованную, но часто достаточно ясно, когда понятия Jodatime понятны. И ИМО мало чем связано с "слоями", возможно, больше для использования случаев или сценариев.
Нетривиальный пример -порядка: вы работаете в Google, программируя Календарь. Вы должны позволить пользователю управлять (добавлять, видеть, изменять) событие, которое включает дату-дату (позволяет игнорировать повторяющиеся события), например: "У меня есть назначение с моим врачом в 2019-июле-3 в 10:00". Какая сущность времени для использования на программном уровне (для этой утилиты)? Я бы сказал: a LocalDateTime. Поскольку пользователь не имеет дело с физическим моментом времени, но с гражданским временем: дата и время, которое отображает часы в его запястье или в его доме. Он даже не думает о часовых поясах (позволяет игнорировать особый случай пользователя, который путешествует по всему миру...) Затем, на уровне бизнеса и презентации, LocalDateTime кажется правильной сущностью.
Но предположим, что вы также должны кодировать другой сценарий: напоминание. Когда внутренний планировщик Google обнаруживает, что событие, хранящееся пользователем, в будущем будет N минут в будущем, оно должно отправить ему напоминание. Здесь "N минут спустя" является полностью "физической" концепцией времени, поэтому здесь "бизнес-уровень" будет иметь дело с DateTime. Существует несколько альтернатив, например: событие хранилось в БД как LocalDateTime (то есть просто время и дата без часового пояса - для представления этого часто используется временная метка UTC, но это деталь реализации). В этом сценарии (только в этом) мы должны загрузить его как DateTime, мы его преобразуем с использованием часового пояса, возможно, из профиля пользователя.