Java Date & Time API の何が問題なのでしょうか? [closed] 質問する

ああ、JavaDateクラス。おそらく、どの言語でも、どこででも、やってはいけないことの最も良い例の 1 つです。どこから始めればいいでしょうか?

JavaDocを読むと、開発者は実際に良いアイデアを持っていると思うかもしれません。UTCそしてGMT両者の差は基本的にうるう秒（かわいい めったに）。

しかし、設計上の決定は、API が適切に設計されているという思いをまったく台無しにします。よくある間違いをいくつか挙げます。

• 2000 年の最後の 10 年間に設計されたにもかかわらず、1900 年からの年数を 2 桁で評価します。このありふれた決定の結果として、Java の世界では文字通り 1900+ (または 1900-) を実行する回避策が何百万もあります。
• 月はゼロでインデックス付けされます。これは、月の配列があり、最初の要素に が含まれる 13 要素の配列ではないという非常に珍しいケースに対応するためですnull。結果として、0..11 になります (今日は 109 年 11 月です)。文字列に変換するために、月には同様の数の ++ と -- があります。
• 彼らは可変その結果、日付を返す必要があるときはいつでも (たとえば、インスタンス構造として)、日付オブジェクト自体ではなく、その日付のクローンを返す必要があります (そうしないと、構造が変更される可能性があるため)。
• これを「修正」するために設計されたはCalendar、実際には同じ間違いを犯します。それらは依然として変更可能です。
• Dateは を表しますDateTimeが、SQL の世界に従うために、別のサブクラス がありjava.sql.Date、これは 1 日を表します (ただし、タイムゾーンは関連付けられていません)。
• TimeZoneには が関連付けられていないDateため、範囲（「丸一日」など）は深夜から深夜まで（多くの場合、任意のタイムゾーン）として表されることが多い。

最後に、うるう秒は、通常、1 時間以内に ntp で更新される適切なシステム クロックに対して自動的に修正されることに注意してください (上記のリンクを参照)。2 回のうるう秒の導入 (最低でも 6 か月ごと、実質的には数年ごと) でシステムがまだ稼働している可能性は非常に低く、特に、時々新しいバージョンのコードを再デプロイする必要があることを考慮すると、その可能性は低くなります。クラスを再生成する動的言語や WAR エンジンのようなものを使用した場合でも、クラス スペースが汚染され、最終的には permgen が不足します。