25

私は最近、Javaで日付を操作するための非常に単純なライブラリ（基本的には単一のクラス）であるdate4jに出くわしました。概念的には、date4jの「アイデア」が本当に好きです。実際、メインサイト全体とjavadocのドキュメントの両方を読んだ後、私は述べられているすべてにほぼ同意します。

さて、date4jを使用すべきでない理由はいくつかあるかもしれません-バグ、パフォーマンス、ユーザーの不足などです。私はそれらのことについて質問していません。概念的には、date4j（そこにあるほとんどのアプリケーション）のアイデアの何が問題になっていますか？確かに、jodaやthreetenのようなものを必要とするアプリケーションがあるかもしれませんが、それらは少数派であると私は信じています。

日付/時刻を扱うユーザー（ほとんどすべての人がJavaアプリを作成している）に人々が与える通常のアドバイスは、次のようなものです。

  • java.util.Calendarの代わりにjoda-timeを使用する
  • WebサーバーをUTCに設定します
  • データベースサーバーをUTCに設定します
  • 日時をUTCで保存します

実際、最後の3つの箇条書きは、日付を操作するときに人々が抱える現在のメンタルモデルの問題を示しています。人々は、アプリケーションレベルとデータベースレベルの両方でタイムゾーンを管理しようとします（ORMフレームワークは、物事をさらに複雑にする別の抽象化レイヤーを追加することは言うまでもありません）。

あなたはそれらのことをする必要はないはずです。たとえば、java.util.Calendarを使用していて、ユーザー定義のタイムゾーンで時間を操作している場合は、次のようになります。

Calendar c = Calendar.getInstance(TimeZone.getTimeZone("America/New_York"));
c.set(Calendar.YEAR, 2011);
c.set(Calendar.MONTH, 0);
c.set(Calendar.DAY_OF_MONTH, 1);
c.set(Calendar.HOUR_OF_DAY, 3);
c.set(Calendar.MINUTE, 0);
c.set(Calendar.SECOND, 0);
c.set(Calendar.MILLISECOND, 0);

これは、タイムゾーンに関係なく、時間の「インスタント」を表します。今回は、データベースとの間で「変換」が発生することを心配せずに永続化できるはずです。データベースが上海のタイムゾーンにあり、Webサーバーがロサンゼルスのタイムゾーンにあるかどうかは関係ありません。時間の瞬間は関係なく同じです。

1つの問題は、一部のデータベースがタイムゾーンを管理しようとし（私はあなたを見ています、Postgres！grr！）、さらに悪いことに、JDBCドライバーレベルでの動作はベンダー固有です（つまり、PreparedStatement.setDate / getDate）。

date4jが使用するメンタルモデルは、すべての混乱を取り除くようです。たとえば、now（）を呼び出すときに、明示的に使用を強制してタイムゾーンを提供します。このサイトには、ライブラリを使用するための非常に優れた推奨事項がいくつかあります（これらは、以前に自分のアプリですでに行っていたものです）。

  • タイムゾーンを管理しようとするデータベースタイプを使用しないでください
  • タイムゾーンを別の列として保存する（必要な場合）

date4jのようなライブラリを採用する人が増えないのはなぜですか？

4

2 に答える 2

7

I've never looked at date4j until now, but I read through the documentation, and I have one concrete problem, and one opinion about what is wrong with it.

First, the concrete problem. It does not maintain Timezone internally. So there is ambiguity about daylight saving. Consider the transition Sunday when 1:59:59am (EDT) becomes 1:00:00am (EST). Clearly, in that day, saying 1:30am is ambiguous. That time happens twice. So the following is ambiguous

new DateTime("2011-11-06 01:30:00")

Second, my opinion. The problem with Date was that it didn't maintain Timezone. By the time Calendar came along, the damage was done. Furthermore, Calendar itself didn't do itself any favors by being mutable. But at the heart, the solution has to include not just moment, but where it was perceived -- timezone, culture, locale sort of stuff. These then need to be maintained alongside the moment when persisted to database, serialized, communicated, whatever. This same personal principle makes me humbly suggest that even xsd:dateTime falls short because it simply allows a date+time to be expressed relative to UTC, it has no provisions to supply whether, for example, daylight saving was being observed.

于 2011-08-25T05:23:14.903 に答える
1

それは4年後です、そして私はこの質問に出くわしました。私にとって、date4jの問題＃1はバグです。あなたが特にそれらについて尋ねなかったことを私は知っています、しかしそれは大きな問題です。

より具体的には、バグ自体はそれ自体では問題ではありません。date4jについて私を悩ませているのは、ある種のバグ報告システムがまったくないことです。私の知る限り、メーリングリストすらありません。何もありません。日付/時刻APIがどのようなものであるかについての議論では、これはおそらくあまり興味深いことではないことを私は知っていますが、それでもインフラストラクチャは重要です。

図書館が広く採用されていない理由は、図書館が不足していることが原因かもしれません。

于 2015-07-01T16:38:21.543 に答える