で野田タイム・ユーザーズ・ガイド、根拠セクションの状態：
パブリックAPIは、.NETにより慣用的なAPIを提供するとともに、野田タイムチームが「不幸」と見なしているJoda Timeの決定の一部を修正するために、大幅に書き直されました。（これらのいくつかは、単に異なる目標を持っていることが原因です;私が主張する他のものは本当に間違いです。）
異なる/より良いこれらの決定は何ですか？これは、言語の構文だけの違いを数えるものではありませんが、ユーザーがプログラミングエラー（ライブラリの使いやすさ）を起こしにくいようにするために行われることはすべて含まれます。
回答:
開始するのに最適な場所は、おそらくユーザーガイドの「設計哲学」セクションです。しかし、野田時間とジョーダ時間の特定の違いをレイアウトするには：
野田タイムはそのコードの多くを内部に保持しています。これにより、実際に独自のカレンダーシステムを作成できないという点で柔軟性が低下しますが、APIの学習と使用の両方が簡単になることも意味します。
野田時間では、ほとんどの場合、無効はエラーです。これ以上「タイムゾーンにnullを渡した場合、システムのデフォルトを使用するだけです」。明示的にする必要があります。
デフォルトといえば...システムクロックをデフォルトとして使用しません。実装IClockとは別のインターフェースを持っていますが、SystemClockデフォルトでは「現在の時刻」はありません。
特定のビルダークラスを除き、すべては不変です。MutableDateTimeJoda Timeの（など）は間違いだったと思います。
カレンダーシステムとタイムゾーンは、実際には非常に異なる懸念事項であるため、互いに分離しています。そのLocalDateため、たとえば、タイムゾーンではなく、使用するカレンダーシステムについて知っています。
ローカルの日付/時刻値をゾーン化された日付/時刻値に解決する方法は、Joda TimeよりもJSR-310に近いです。あいまいさやスキップされた時間を特定の方法で処理するだけではありません。ユーザーに自分が望むものを言うようにします。
Joda Timeには、弱く型付けされたAPI（newなどInstant(Object)）から何が欲しいかを推測しようとするさまざまな場所があります。野田タイムは、可能な限りこれを回避します-より明確です。
野田時間は、どのタイプに対してどのような演算を実行できるかについてより厳密です。したがって、たとえば、a Periodをa ZonedDateTimeに追加することはできません。これは、夏時間に移行する際に混乱が生じる可能性があるためです。代わりに、に変換することをお勧めしますがLocalDateTime、ゾーン化されていないコンテキストで必要な多くの算術を実行してから、元に戻します。
野田タイムは継承をかなり少なく使用します。ジョダタイムの階層は非常に深く複雑です。多くの野田時間は値の型に基づいているという事実は、とにかくこれを実際に強制しますが、まだクラス継承を使用している場所がいくつかありますが、私は継承階層を大幅に崩壊させることができました...しばしば犠牲になります私は価値があるとは思わなかった柔軟性の:)