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

Are there any cons to using Joda-Time?

提问by user2427

I want to convince the architecture manager to include the Joda-Timejar in our product.

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

Do you know any disadvantages in using it?

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

I think Joda-Time needs to be constantly updated because of the files that it includes. And that is a disadvantage. Maybe I am wrong.

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

Could you provide some clarity on the subject?

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

采纳答案by Jon Skeet

I've had almost entirely positive experiences with Joda Time. My one problem was when trying to construct my own time zone (for legitimate reasons, I assure you :) I got some very weird exceptions, and the documentation wasn't very good for that particular use case.

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

However, for the most part it's been a joy to use - immutability makes code a lot easier to reason about, and thread-safety for formatters is hugely useful.

然而，在大多数情况下，使用起来很愉快——不变性使代码更容易推理，并且格式化程序的线程安全非常有用。

Yes, there are files to keep up to date - but at least you cankeep them up to date. It's not like they contain things which were unnecessary with Java's built-in stuff, it's just that with Java's mechanism you just couldn't keep information like timezones up to date without significant hackery!

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

Basically, +1 for using Joda Time. The Java date/time API is one of the worst bits of the Java platform, IMO.

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

回答by John O

In my opinion, the most important drawback in Joda-Time is about precision: many databases store timestamps with microsecond(or even nanosecond) precision. Joda-time goes only to milliseconds. This is not acceptable to me: all "data model" classes that I use need to reflect the full precision of the data in my database. Approximations or truncations of my data by a library just don't cut it.

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

Here is the reasoning behind the choice of millisecond precision, taken from the JSR 310mailing list:

以下是选择毫秒精度的原因，摘自JSR 310邮件列表：

"Joda-Time chose to use milliseconds as it made conversions to Date and Calendar easier."- S. Colebourne

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

Easier for whom? The author of the library, one would assume... Incorrect design decision, in my opinion, when almost all databases store times to microsecond/nanosecond precision. The disregard for database values is worrying.

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

回答by Matt Poush

The biggest issue that we had when using Joda Time was with integration with Spring and Tapestry, as they both wanted to use the built-in Date and Time. We were constantly writing wrappers in getters/setters for date and time: either we would store it as Joda Time and one set of getters/setters passed it through and the other would convert on the fly, and some classes stored it internally as a Java Date/Time, and the Joda getter/setter had to switch it on the fly.

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

Basically, it was a headache because the classes are similarly named, and unless you can get your entire architecture (including other libraries you're integrating) to switch to Joda Time, you are going to write more wrapper code than you are likely to save by using the Joda libraries.

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

回答by Barend

Parleys hosts a presentation by Stephen Colebourne about JSR-310, Mr. Colebourne the author of Joda-Time and JSR-310. He starts out by explaining the weaknesses of the standard date/time support in Java and why you'd want to use an alternative. It may be helpful to show this presentation to your architecture manager. I can't seem to deep-link

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

The reason Joda-Time updates its timezone file fairly often is because timezone data changes all the time, often on short notice (today on slashdot: leap second added on 2008-12-31) and not always scientifically motivated (e.g. I recall some pacific island state changed its time zone to be the first country to enter the year 2000).

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

回答by Paul Tomblin

In the past, I've encountered companies that didn't want to incorporate third party open source software, or at least required the company lawyer to certify that the license wasn't going to expose them to any sort of liability or have a viral effect on their product.

过去，我遇到过不想合并第三方开源软件的公司，或者至少要求公司律师证明许可证不会使他们承担任何责任或病毒传播对其产品的影响。

As with any third party libraries, you should probably put it into source control so you can find the version that you shipped with particular releases of your code in case something goes wrong.

与任何第三方库一样，您可能应该将其置于源代码控制中，以便您可以找到随特定代码版本一起提供的版本，以防出现问题。

回答by Steven J. Hathaway

The choice of milliseconds for the underlying time continuum is good for implementing calendars of antiquity, and special calendars. Unlike many counters, the 64-bit millisecond counter has good range coverage for calendars of antiquity, with rollover properties in excess of +/- 260 million years.

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

It does not handle leap seconds. This is a good thing. A smooth transition is proposed by the atomic clock folks to allow systems that do not deploy leap seconds to incrementally adjust their clocks over 100 seconds to accommodate the leap second correction.

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

Maintenance of timezone tables will also be an issue.

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

The underlying continuum also allows an old French calendar and clock that divided a day into 10 intervals called metric time instead of 24 hours. The classic Chinese calendar divides a day into 100 increments, each just over 14 minutes in length. All of these calendars can be implemented and coordinated on the underlying millisecond time continuum.

基础连续体还允许使用古老的法国日历和时钟，将一天分为 10 个称为公制时间的间隔，而不是 24 小时。传统的 CN 历法将一天分为 100 个增量，每个增量刚好超过 14 分钟。所有这些日历都可以在基础毫秒时间连续体上实施和协调。

回答by Archimedes Trajano

The main issue with it is vendor lockin at least until it becomes part of the standard.

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

For the most part I would use longs to store any business date information on a database. This gives me the flexibility to adjust the precision as I see fit. In most cases I just convert them to java.util.Date.

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

Time zones I would treat to be a presentation level issue than a data issue. This simplifies the database and increases portability since databases can represent temporals in different fashions.

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

The standard Calendar class provides me with some date manipulation functions which I convert to millisecond since epoch data.

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

As for nanosecond precision I would store that as an offset from 0 as a separate long column.

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