使用 Joda-Time 有什么缺点吗？答案

【问题标题】：Are there any cons to using Joda-Time?使用 Joda-Time 有什么缺点吗？
【发布时间】：2010-09-27 09:28:02
【问题描述】：

我想说服架构经理将Joda-Time jar 包含在我们的产品中。

你知道使用它有什么缺点吗？

我认为 Joda-Time 需要不断更新，因为它包含的文件。这是一个缺点。也许我错了。

您能否就该主题提供一些说明？

【问题讨论】：

仅供参考，Joda-Time 项目现在处于维护模式，并建议迁移到其继任者 java.time。 java.time 类是 Java SE（标准版）的一部分，内置于版本 8 及更高版本中。可用于大部分功能的后向端口：for Java 6 & 7 和 for Android。

标签： java jodatime

【解决方案1】：

我在 Joda Time 获得了几乎完全积极的体验。我的一个问题是在尝试构建自己的时区时（出于正当原因，我向您保证 :) 我遇到了一些非常奇怪的异常，并且文档对于该特定用例并不是很好。

但是，在大多数情况下，使用它是一种乐趣 - 不变性使代码更容易推理，并且格式化程序的线程安全非常有用。

是的，有些文件需要保持最新 - 但至少您可以保持它们是最新的。这并不是说它们包含 Java 内置的东西不需要的东西，只是使用 Java 的机制，你无法在没有重大黑客攻击的情况下使时区等信息保持最新！

基本上，+1 用于使用 Joda Time。 Java 日期/时间 API 是 Java 平台 IMO 中最糟糕的部分之一。

【讨论】：

有人可以提供有关 Joda Time 更新的详细信息吗？具体来说，我想知道 Joda Time 是否会强制您使文件保持最新。我工作的公司在更新它的库方面非常保守（这就像拔牙让它们更新，更不用说请求一个新的了），我想在我提出请求之前知道它是如何工作的。例如，如果 Joda Time 没有找到更新的文件就停止工作，那么风险太大。

【解决方案2】：

在我看来，Joda-Time 最重要的缺点是精度：许多数据库以microsecond（甚至nanosecond）精度存储时间戳。 Joda-time 只发给milliseconds。这对我来说是不可接受的：我使用的所有“数据模型”类都需要反映数据库中数据的完整精度。图书馆对我的数据的近似或截断只是不削减它。

这里是选择毫秒精度背后的原因，取自JSR 310邮件列表：

“Joda-Time 选择使用毫秒，因为它可以更轻松地转换为日期和日历。” - S. Colebourne

对谁来说更容易？该库的作者会假设...在我看来，当几乎所有数据库都将时间存储到微秒/纳秒精度时，设计决策不正确。对数据库值的忽视令人担忧。

【讨论】：

如果您是处理亚原子粒子的问题域，我可以看到微秒或纳秒精度很重要。而且我也可以理解，如果您的数据库具有微/纳米值，您不希望这些值被截断。但是对于 99% 的用例来说，毫秒精度就足够了。
Oracle、DB2 和 PostgreSQL 都可以将时间戳值存储到微秒或更高精度。那些几乎不是晦涩难懂的数据库，现在是吗？
John O - 我没说数据库晦涩难懂。我的观点是，对于大多数用例来说，这种精度并不重要。仅仅因为您的数据库可以存储该精度并不意味着您必须这样做。 Joda time 是一个很好的工具，除非您的用例需要更高精度的日期，否则不值得淘汰。对于这些情况，如果您不希望发生近似值或截断，只需以毫秒精度存储日期。当然，如果您的应用程序需要微米或纳米精度，那么 Joda time 可能不是最适合这项工作的工具。
Joda-Time 的继任者java.time 具有nanosecond 分辨率。

【解决方案3】：

我们在使用 Joda Time 时遇到的最大问题是与 Spring 和 Tapestry 的集成，因为它们都想使用内置的日期和时间。我们经常在 getter/setter 中为日期和时间编写包装器：要么我们将其存储为 Joda Time，一组 getter/setter 传递它，另一组即时转换，一些类在内部将其存储为 Java日期/时间，Joda getter/setter 必须即时切换。

基本上，这是一个令人头疼的问题，因为这些类的名称相似，除非您可以让您的整个架构（包括您正在集成的其他库）切换到 Joda Time，否则您将编写比实际更多的包装器代码可能会通过使用 Joda 库来节省。

【讨论】：

我不了解 Tapestry，但是在 Spring 中编写自己的转换器非常容易，因此 Spring config 文件当然可以轻松处理 Joda Time。诚然，它自己的一些库可能更痛苦。
从 Spring MVC v3 开始，如果你的类路径中有 Joda Time JAR，@DateTimeFormatter annotation 会自动支持 Joda Time 类。我一直在使用它，并且不必进行任何包装或转换以绑定到表单等（诚然，我的堆栈已经是 Joda-all-the-way-down 了）跨度>
精彩的Tapestry Jumpstart 涵盖了Joda Time with Tapestry 的使用。 Here 和 here.

【解决方案4】：

Parleys 主持 a presentation by Stephen Colebourne about JSR-310，Joda-Time 和 JSR-310 的作者 Colebourne 先生。他首先解释了 Java 中标准日期/时间支持的弱点以及为什么要使用替代方案。将此演示文稿展示给您的架构经理可能会有所帮助。我似乎无法进行深层链接

Joda-Time 经常更新其时区文件的原因是时区数据一直在变化，通常是在短时间内（今天在 slashdot 上：leap second added on 2008-12-31）并且并不总是出于科学动机（例如，我记得一些太平洋岛屿状态发生了变化它的时区是第一个进入 2000 年的国家）。

【讨论】：

【解决方案5】：

过去，我遇到过不想整合第三方开源软件的公司，或者至少要求公司律师证明许可证不会让他们承担任何责任或对他们的产品产生病毒效应。

与任何第三方库一样，您可能应该将其置于源代码管理中，以便在出现问题时找到随特定版本发布的代码。

【讨论】：

Joda-Time 的继任者 java.time 现在确实是 Java SE（标准版）的一部分，内置于版本 8 及更高版本中。因此无需担心第三方问题。

【解决方案6】：

选择毫秒作为基础时间连续体有利于实现古代日历和特殊日历。与许多计数器不同，64 位毫秒计数器对古代日历具有良好的覆盖范围，具有超过 +/- 2.6 亿年的翻转特性。

它不处理闰秒。这是一件好事。原子钟专家提出了一种平滑过渡，以允许未部署闰秒的系统在 100 秒内逐步调整其时钟以适应闰秒校正。

时区表的维护也是一个问题。

底层连续统一体还允许使用旧的法国日历和时钟，将一天分为 10 个间隔，称为公制时间，而不是 24 小时。经典的中国历法将一天分为 100 个增量，每个增量仅超过 14 分钟。所有这些日历都可以在底层的毫秒时间连续体上实施和协调。

【讨论】：

仅供参考……Joda-Time 的继任者java.time 具有nanosecond 分辨率。

【解决方案7】：

它的主要问题是供应商锁定，至少在它成为标准的一部分之前。

在大多数情况下，我会使用 long 将任何业务日期信息存储在数据库中。这使我可以灵活地调整我认为合适的精度。在大多数情况下，我只是将它们转换为 java.util.Date。

我将时区视为演示级别问题而不是数据问题。这简化了数据库并增加了可移植性，因为数据库可以以不同的方式表示时间。

标准 Calendar 类为我提供了一些日期操作函数，我将它们转换为自纪元数据以来的毫秒数。

至于纳秒精度，我会将其存储为从 0 开始的偏移量作为单独的长列。

【讨论】：

Joda-Time 的继任者 java.time 现在确实是 Java SE（标准版）的一部分，内置于版本 8 及更高版本中。后端端口可用for Java 6 & 7 和for Android。