我想说服架构经理在我们的产品中包含Joda-Time jar。
你知道使用它有什么缺点吗？
我认为 Joda-Time 需要不断更新，因为它包含的文件。这是一个缺点。也许我错了。
您能否就该主题提供一些说明？
damian
问问题
17041 次
7 回答
58
我对 Joda Time 的体验几乎完全是积极的。我的一个问题是在尝试构建自己的时区时（出于正当原因，我向您保证 :) 我遇到了一些非常奇怪的异常，并且文档对于该特定用例并不是很好。
然而，在大多数情况下，使用它是一种乐趣——不变性使代码更容易推理，并且格式化程序的线程安全非常有用。
是的，有些文件需要保持最新——但至少你可以让它们保持最新。这并不是说它们包含 Java 内置的东西不需要的东西，只是使用 Java 的机制，如果没有重大的黑客攻击，你就无法保持时区等信息是最新的！
基本上，+1 用于使用 Joda Time。Java 日期/时间 API 是 Java 平台 IMO 中最糟糕的部分之一。
于 2008-12-17T19:49:50.393 回答
35
11
我们在使用 Joda Time 时遇到的最大问题是与 Spring 和 Tapestry 的集成，因为它们都想使用内置的日期和时间。我们经常在 getter/setter 中为日期和时间编写包装器：要么我们将其存储为 Joda Time，一组 getter/setter 传递它，另一组即时转换，一些类在内部将其存储为 Java日期/时间，Joda getter/setter 必须即时切换它。
基本上，这是一个令人头疼的问题，因为这些类的名称相似，除非您可以让您的整个架构（包括您正在集成的其他库）切换到 Joda Time，否则您将编写比您可能保存的更多的包装器代码通过使用 Joda 库。
于 2008-12-17T18:46:58.587 回答
5
Parleys 主持了 Stephen Colebourne 关于 JSR-310 的演讲，Colebourne先生是 Joda-Time 和 JSR-310 的作者。他首先解释了 Java 中标准日期/时间支持的弱点以及为什么要使用替代方案。将此演示文稿展示给您的架构经理可能会有所帮助。我似乎无法深层链接
Joda-Time 经常更新其时区文件的原因是因为时区数据一直在变化，通常是在短时间内（今天在 slashdot：leap second added on 2008-12-31）并且并不总是出于科学动机（例如，我记得一些太平洋岛国改变了时区，成为第一个进入 2000 年的国家）。
于 2008-12-29T14:50:59.673 回答
2
过去，我遇到过不想包含第三方开源软件的公司，或者至少要求公司律师证明许可证不会让他们承担任何责任或病毒传播对其产品的影响。
与任何第三方库一样，您可能应该将其放入源代码管理中，以便在出现问题时可以找到与特定版本的代码一起发布的版本。
于 2008-12-17T18:40:44.900 回答
2
为基础时间连续体选择毫秒有利于实现古代日历和特殊日历。与许多计数器不同，64 位毫秒计数器对古代日历具有良好的范围覆盖，具有超过 +/- 2.6 亿年的翻转特性。
它不处理闰秒。这是一件好事。原子钟人员提出了一种平滑过渡，以允许未部署闰秒的系统在 100 秒内逐步调整其时钟以适应闰秒校正。
时区表的维护也将是一个问题。
底层连续统一体还允许使用古老的法国日历和时钟，将一天分为 10 个间隔，称为公制时间，而不是 24 小时。经典的中国历法将一天分为 100 个增量，每个增量仅超过 14 分钟。所有这些日历都可以在底层毫秒时间连续体上实施和协调。
于 2012-04-18T04:15:18.033 回答
0
它的主要问题是供应商锁定，至少在它成为标准的一部分之前。
在大多数情况下，我会使用 long 将任何业务日期信息存储在数据库中。这使我可以灵活地调整我认为合适的精度。在大多数情况下，我只是将它们转换为 java.util.Date。
我将时区视为演示级别问题而不是数据问题。这简化了数据库并增加了可移植性，因为数据库可以以不同的方式表示时间。
标准 Calendar 类为我提供了一些日期操作函数，我将它们转换为自纪元数据以来的毫秒数。
至于纳秒精度，我会将其存储为从 0 开始的偏移量作为单独的长列。
于 2014-01-01T06:55:09.247 回答