野田时间vs乔达时间？

在《Noda Time用户指南》中，基本原理部分指出：

公共API已被大量重写，以提供对.NET更惯用的API，并纠正Noda Time团队认为“不幸”的一些Joda Time决定。（其中一些仅仅是由于具有不同的目标；我认为其他一些确实是错误。）

这些不同/更好的决定是什么？这将不仅仅考虑语言语法的差异，而是将包括所有使用户不太可能发生编程错误（库可用性）的工作。

最好的起点可能是用户指南的“设计理念”部分。但要列出Noda Time和Joda Time之间的具体区别：

• Noda Time将更多代码保留在内部。这使灵活性降低，因为您实际上无法创建自己的日历系统-而且意味着该API更易于学习和使用。

• 在Noda Time中，无效几乎总是错误。不再需要“如果在某个时区输入null，我们将使用系统默认值”。您需要明确。

• 说到默认值...我们不使用系统时钟作为默认值。我们有一个IClock带有SystemClock实现的单独接口，但是没有默认值为“当前时间”。

• 除了特定的构建器类之外，所有内容都是不可变的。我认为MutableDateTime（等）《乔达时报》是个错误。

• 我们已经将日历系统和时区彼此分开，因为它们确实是非常不同的关注点。因此，例如，您LocalDate知道它使用的日历系统，但不知道时区。

• 将本地日期/时间值解析为分区日期/时间值的方式比Joda Time更接近JSR-310。我们不仅仅以某种特定的方式处理歧义/跳过的时间：我们让用户说出他们想要什么。

• Joda Time在很多地方都试图从弱类型的API（例如new Instant(Object)）中猜测您想要的内容。Noda Time尽可能避免这种情况-更加明确。

• Noda Time在可以对哪种类型执行的算术上更为严格。因此，例如，你不能添加Period到ZonedDateTime，因为周围有夏令转变可能误事古怪。相反，我们鼓励用户转换为LocalDateTime，在非分区上下文中执行他们想执行的任何算法，然后再转换回去。

• Noda Time使用继承的方式要少得多-Joda Time中的层次结构非常复杂。实际上，很多Noda Time都是基于值类型的事实实际上仍然在强制执行此操作，但是在某些地方我们仍在使用类继承，但是我设法使继承层次结构显着瓦解了……通常为此付出了代价灵活性，我认为这不值得：)