关于datetime：Java 8 Date Time API（java.time）和Joda-Time之间的差异

Differences between Java 8 Date Time API (java.time) and Joda-Time

我知道有一些与java.util.date和joda time相关的问题。但是经过一些挖掘之后，我找不到关于JavaTime API(JavaSudio 8中定义的JSR 310)和JoDA时间之间的差异的线索。

我听说Java 8的JavaTime API更干净，可以比JoDA时间做得多。但我找不到比较这两者的例子。

java.time能做什么？joda time不能做什么？
java.time能比joda time做得更好吗？
java.time的性能更好吗？

常见特征好的。

a)两个库都使用不可变类型。Joda Time还提供其他可变类型，如MutableDateTime。好的。

b)此外：两个库都受到Eric Evans的设计研究"时间和金钱"或Martin Fowler关于域驱动风格的想法的启发，因此它们或多或少地努力获得一种流畅的编程风格(尽管并非总是完美的；-)。好的。

c)使用这两个库，我们可以得到一个真实的日历日期类型(称为LocalDate)，一个真实的墙时间类型(称为LocalTime)和组合(称为LocalDateTime)。这是一个非常大的胜利，相比之下，旧的java.util.Calendar和java.util.Date。好的。

d)两个库都使用以方法为中心的方法，这意味着它们鼓励用户使用getDayOfYear()，而不是get(DAY_OF_YEAR)。与java.util.Calendar相比，这会导致许多额外的方法(尽管后者根本不是类型安全的，因为过度使用ints)。好的。

性能好的。

另一个答案是@oo7，指向Mikhail Vorontsov的分析，尽管第3点(异常捕获)可能已经过时了——请看这个JDK错误。不同的性能(通常有利于JSR-310)主要是由于joda time的内部实现总是使用类似于long-primitive的机器时间(以毫秒为单位)。好的。

无效的好的。

Joda Time通常使用空作为系统时区、默认区域设置、当前时间戳等的默认值，而JSR-310几乎总是拒绝空值。好的。

精密度好的。

JSR-310处理纳秒精度，而Joda时间限制为毫秒精度。好的。

支持的字段：好的。

Java-8(JSR-310)中受支持字段的概述是由临时包中的一些类(例如ChronoField和WeekFields)提供的，而Joda Time在这一领域相当薄弱——请参见DateTimeFieldType。Joda时间的最大不足是缺少本地化的周相关字段。两种字段实现设计的一个共同特点是，它们都基于long类型的值(没有其他类型，甚至不是枚举)。好的。

枚举好的。

JSR-310提供了EDOCX1，9，EDCX1，10的枚举，而JoDA时间不提供这一点，因为它主要是在Java 5之前在2002年-2004年开发的。好的。

区域API好的。

a)JSR-310比Joda Time提供更多时区功能。后者无法以编程方式访问时区偏移转换的历史记录，而JSR-310能够做到这一点。好的。

b)供您参考：JSR-310已经将其内部时区存储库移到了一个新的位置并采用了不同的格式。旧库文件夹lib/zi不再存在。好的。

调整人与财产好的。

JSR-310将TemporalAdjuster接口作为一种形式化的方法引入到外部化时间计算和操作中，特别是对于库或框架编写者来说，这是一种嵌入JSR-310新扩展(相当于以前java.util.Date的静态助手类)的很好且相对简单的方法。好的。

然而，对于大多数用户来说，这个特性的价值非常有限，因为编写代码的负担仍然由用户承担。基于新TemporalAdjuster概念的内置解决方案并不多，目前只有助手类TemporalAdjusters具有有限的操作集(以及enums Month或其他时间类型)。好的。

Joda Time提供了一个字段包，但实践证明，新的字段实现很难编码。另一方面，Joda Time提供了所谓的属性，这使得一些操作比JSR-310(例如property.withMaximumValue())更容易、更优雅。好的。

日历系统好的。

JSR-310提供4个额外的日历系统。最有趣的是乌马尔库拉(在沙特阿拉伯使用)。另外三个是：明国(台湾)，日语(只有1871年以来的现代历法！)以及塔伊布迪施特(仅在1940年之后才正确)。好的。

Joda Time提供了一种基于计算基础的伊斯兰日历，而不是乌马尔库拉那样的基于观测的日历。泰国佛教徒也以类似的形式提供给乔达时代，明国和日本的佛教徒不提供。否则，Joda Time也提供科普特和埃塞俄比亚日历(但不支持国际化)。好的。

欧洲人更感兴趣的是：Joda Time还提供公历、儒略历和混合公历儒略历。然而，实际历史计算的实用价值是有限的，因为根本不支持历史不同年份开始的重要特征(同样的批评也适用于旧的java.util.GregorianCalendar)。好的。

其他的历法，如希伯来语、波斯语或印度教，在这两个图书馆都完全不见了。好的。

划时代的日子好的。

JSR-310具有类julianfields，而joda-time(版本2.0)在类datetimeutils中提供了一些助手方法。好的。

钟好的。

JSR-310没有接口(设计错误)，而是一个抽象类java.time.Clock，可以用于任何时钟依赖注入。joda time在datetimeutils中提供了接口millisprovider和一些助手方法。因此，Joda Time还能够支持具有不同时钟(模拟等)的测试驱动模型。好的。

持续时间算法好的。

两个库都支持以一个或多个时间单位计算时间距离。但是，当处理单个单元持续时间时，JSR-310-Style显然更好(并且基于long而不是使用int)：好的。

JSR-310=>long days = ChronoUnit.DAYS.between(date1, date2);。好的。

乔达时间=>int days = DAYS.daysBetween(date1, date2).getDays();。好的。

处理多个单元的持续时间也是不同的。即使计算结果也可能不同-请看这个封闭的Joda时间问题。虽然JSR-310使用非常简单和有限的方法仅使用Period类(基于年、月和日的持续时间)和Duration类(基于秒和纳秒)，但JODA时间使用更复杂的方法，使用PeriodType类来控制哪一个单位的持续时间(JODA时间称之为"周期")应表示出来。虽然PeriodTypeAPI在某种程度上难以使用，但JSR-310根本没有提供类似的方法。尤其是在JSR-310中，还不可能定义混合的日期和时间(例如，基于天和小时)。因此，如果涉及到从一个库到另一个库的迁移，就要受到警告。讨论中的库不兼容-尽管类名部分相同。好的。

间隔好的。

JSR-310不支持此功能，而Joda Time的支持有限。也请看这个答案。好的。

格式化和解析好的。

比较两个库的最佳方法是查看同名类DateTimeFormatterBuilder(JSR-310)和DateTimeFormatterBuilder(Joda Time)。JSR-310变体的功能稍强(也可以处理任何类型的TemporalField，前提是字段实现者已经设法对一些扩展点(如resolve())进行了编码)。然而，最重要的区别是——在我看来：好的。

JSR-310可以更好地解析时区名称(格式模式符号Z)，而Joda Time在其早期版本中根本无法做到这一点，现在只能以非常有限的方式做到这一点。好的。

JSR-310的另一个优点是支持独立月份名称，这在俄语或波兰语等语言中很重要。Joda Time无法访问这些资源，甚至在Java-8平台上也无法访问。好的。

JSR-310中的模式语法也比Joda Time更灵活，允许可选部分(使用方括号)，更倾向于CLDR标准，并提供填充(字母符号P)和更多字段。好的。

否则，应该注意，Joda Time可以使用PeriodFormatter格式化持续时间。JSR-310不能这样做。好的。

希望这个概述有帮助。所有收集到的信息主要是由于我的努力和调查，如何设计和实现一个更好的日期和时间库(没有什么是完美的)。好的。

2015-06-24更新：好的。

同时，我发现了编写和发布Java中不同时间库的表格概述的时间。这些表还包含Joda Time v2.8.1和Java-8(JSR-310)之间的比较。比这篇文章更详细。好的。好啊.