Joda-Timeライブラリにはさまざまな日時クラスが含まれています
Layered Applicationsでこれらのクラスをどのように使用しているのか疑問に思っています。
アプリケーションがタイムゾーンを管理する必要がなく、時間を常に UTC で安全に想定できるように、(少なくともサービス層で) LocalDateTime を使用するほぼすべてのインターフェイスを持つことには利点があります。私のアプリは、DateTime を使用して、実行のフローの最初でタイムゾーンを管理できます。
また、DateMidnight がどのシナリオで役立つのか疑問に思っています。
アプリケーションがタイムゾーンを管理する必要がなく、時間を常に UTC で安全に想定できるように、(少なくともサービス層で) LocalDateTime を使用するほぼすべてのインターフェイスを持つことには利点があります。
ここであなたの考え方を理解しているかどうかはわかりません。LocalDateTimeとは、DateTimeまったく異なる 2 つの概念を表しています。aLocalDateTimeに暗黙の UTC タイムゾーンがあるわけではありません。実際にはタイムゾーンがありません(内部的には UTC タイムゾーンを持つ として表される場合がありますがDateTime、これは単なる実装の詳細であり、それを使用するプログラマーにとっては問題ではありません)。
API ドキュメントを見ると、 aDateTimeは " Instant" (ワールド タイム ラインのポイント、物理的な概念) ですが、aLocalDateTimeはそのようなものではないことがわかります。はLocalDateTime、実際にはPartial、別のクラス階層の (「市民」概念) です。LocalDateTime残念ながら、クラス名から、これはの特殊化だと思われるかもしれませんがDateTime、そうではありません。
Aはペア { ( )LocalDateTimeと見なされるべきです。( )}、時間関連データの「市民」標準表現に対応する一連の数値。が与えられた場合、それを に直接変換することはできません。タイムゾーンを指定する必要があります。そしてその変換は私たちを別の種類の実体へと導きます。(類推: Java の文字列とバイト ストリーム: それらの間で変換するには、概念的に異なるものであるため、文字セット エンコーディングを指定する必要があります)DateY/M/DTimehh:mm:ss.msecLocalDateTimeDateTime
アプリケーションでどちらを使用するか... 議論の余地がある場合もありますが、Jodatime の概念が理解されると、十分に明確になることがよくあります。また、IMO は「レイヤー」とはあまり関係がなく、おそらくユースケースやシナリオに関連しています。
重要な境界線の例: あなたは Google で働いており、カレンダーをプログラミングしています。ユーザーに日時を含むイベントを管理 (追加、表示、変更) させる必要があります (繰り返し発生するイベントは無視します)。たとえば、「2019 年 7 月 3 日の午前 10 時に医師との予約があります」と言います。ソフトウェア層で使用する日時エンティティは何ですか (このユースケースの場合)? 私はこう言いますLocalDateTime：ユーザーが実際に扱っているのは物理的な時点ではなく、一般的な時間、つまり手首や自宅の時計に表示される日付と時刻です。彼はタイムゾーンについても考えていません (世界中を旅しているユーザーの特別なケースは無視しましょう...) そして、ビジネスとプレゼンテーション層では、a LocalDateTimeが適切なエンティティのようです。
しかし、別のシナリオ (リマインダー) もコーディングする必要があるとします。Google の内部スケジューラは、ユーザーが保存したイベントが今から N 分先であることを検出すると、ユーザーにリマインダーを送信する必要があります。ここで、「今から N 分後」は完全に「物理的な」時間の概念であるため、「ビジネス層」はDateTime. たとえば、イベントはDBに保存されましたLocalDateTime（つまり、タイムゾーンなしの時刻と日付-それを表すためにUTCタイムスタンプを頻繁に使用しますが、これは実装の詳細です）。このシナリオ (これのみ) では、それを としてロードする必要がありDateTimeます。おそらくユーザーのプロファイルから、タイムゾーンを使用して変換します。