Joda-Timeを使用することの短所はありますか？
アーキテクチャマネージャに Joda-Time jarを製品に含めるように説得したいと思います。
それを使用する上での不利な点を知っていますか？
含まれているファイルのため、Joda-Timeは常に更新する必要があると思います。そしてそれは不利です。多分私は間違っています。
この件について明確に説明していただけますか？
私はJodaTimeでほぼ完全に前向きな経験をしました。私の1つの問題は、自分のタイムゾーンを構築しようとしたときでした（正当な理由により、保証します:)いくつかの非常に奇妙な例外が発生し、その特定のユースケースではドキュメントがあまりよくありませんでした。
ただし、ほとんどの場合、使用するのは楽しいことです。不変性により、コードの推論がはるかに簡単になり、フォーマッターのスレッドセーフは非常に役立ちます。
はい、最新の状態に保つためのファイルがありますが、少なくともあなたはcanそれらを最新の状態に保つことができます。 Javaの組み込みのものでは不要なものが含まれているわけではありません。Javaのメカニズムでは、重大なハッカーなしではタイムゾーンなどの情報を最新の状態に保つことができなかっただけです。
基本的に、JodaTimeを使用する場合は+1。 Java date/time APIは、Javaプラットフォーム、IMOの最悪のビットの1つです。
私の意見では、Joda-Timeの最も重要な欠点は精度に関するものです。多くのデータベースは、タイムスタンプを マイクロ秒 （または ナノ秒 ）の精度で格納します。 Joda-timeは milliseconds にのみなります。これは受け入れられません。私が使用するすべての「データモデル」クラスは、データベース内のデータの完全な精度を反映する必要があります。ライブラリによるデータの概算または切り捨ては、データをカットしません。
JSR 31 メーリングリストから取得したミリ秒精度の選択の背後にある理由は次のとおりです。
"Joda-Timeは、日付とカレンダーへの変換を容易にするため、ミリ秒を使用することを選択しました。"-S。Colebourne
誰にとって簡単ですか？ライブラリの作成者は、ほぼすべてのデータベースが時間をマイクロ秒/ナノ秒の精度で保存していると思いますが、私の意見では間違った設計決定です。データベース値を無視するのは心配です。
Joda Timeを使用するときに発生した最大の問題は、SpringおよびTapestryとの統合でした。どちらも組み込みの日付と時刻を使用したかったからです。日付と時刻のラッパーをゲッター/セッターに常に書き込んでいました。それをJoda Timeとして保存し、1セットのゲッター/セッターが通過し、他のセットがオンザフライで変換し、一部のクラスが内部で=として保存しましたJava=日付/時刻。Jodaのゲッター/セッターはオンザフライで切り替えなければなりませんでした。
基本的に、クラスの名前が似ているので頭痛の種でした。アーキテクチャ全体（統合する他のライブラリを含む）をJoda Timeに切り替えられない限り、保存するよりも多くのラッパーコードを作成することになります。 Jodaライブラリを使用する。
Parleysのホスト JSR-310に関するStephen Colebourneによるプレゼンテーション 、Joda-TimeとJSR-310の著者であるColebourne氏。彼はまず、Javaでの標準の日付/時刻サポートの弱点と、なぜ代替手段を使用したいのかを説明することから始めます。このプレゼンテーションをアーキテクチャマネージャーに見せることは役立つでしょう。私はディープリンクできないようです
Joda-Timeがタイムゾーンファイルをかなり頻繁に更新する理由は、タイムゾーンデータが常に変更されており、多くの場合短期間で通知されます（今日はスラッシュドット： うるう秒が2008-12-31に追加されました ）。やる気があります（たとえば、ある太平洋の島の州がタイムゾーンを変更して、2000年に入る最初の国になったのを思い出します）。
過去に、サードパーティのオープンソースソフトウェアを組み込みたくない企業や、少なくとも企業の弁護士に、ライセンスが企業をいかなる種類の責任にさらしたり、口コミで広めたりしないことを証明するよう要求した企業に遭遇しました。彼らの製品への影響。
他のサードパーティライブラリと同様に、何か問題が発生した場合に備えて、コードの特定のリリースで出荷されたバージョンを見つけることができるように、おそらくソース管理に入れる必要があります。
基になる時空のミリ秒の選択は、古代のカレンダーや特別なカレンダーを実装するのに適しています。多くのカウンターとは異なり、64ビットのミリ秒カウンターは、+ /-2億6000万年を超えるロールオーバープロパティを備えており、古代のカレンダーを適切にカバーします。
うるう秒は処理しません。これは良いことです。スムーズな移行は、うるう秒を展開しないシステムがうるう秒の修正に対応するために100秒を超えてクロックを段階的に調整できるようにするために原子時計の人々によって提案されています。
タイムゾーンテーブルのメンテナンスも問題になります。
基礎となる連続体は、1日を24時間ではなくメトリック時間と呼ばれる10の間隔に分割した古いフランスのカレンダーと時計も許可します。古典的な中国のカレンダーは、1日を100の増分に分割し、それぞれの長さは14分強です。これらすべてのカレンダーは、基礎となるミリ秒の連続時間で実装および調整できます。
それに関する主な問題は、少なくともそれが標準の一部になるまでのベンダーロックインです。
ほとんどの場合、私はlongを使用して営業日情報をデータベースに保存します。これにより、必要に応じて精度を調整できる柔軟性が得られます。ほとんどの場合、Java.util.Dateに変換するだけです。
タイムゾーンは、データの問題よりもプレゼンテーションレベルの問題として扱います。データベースはさまざまな方法でテンポラルを表すことができるため、これによりデータベースが簡素化され、移植性が向上します。
標準のCalendarクラスは、エポックデータからミリ秒に変換するいくつかの日付操作関数を提供します。
ナノ秒の精度については、0からのオフセットとして別の長い列として格納します。