我想说服架构经理在我们的产品中加入Joda-Time jar。
你知道使用它的任何缺点吗？
我认为Joda-Time需要不断更新，因为它包含的文件。这是一个缺点。也许我错了。
你能否澄清一下这个问题？
答案 0 :(得分：56)
我对Joda Time几乎都有过积极的体验。我的一个问题是在尝试构建我自己的时区时（出于正当理由，我向你保证:)我有一些非常奇怪的异常，而且文档对于那个特定的用例并不是很好。
然而，在大多数情况下使用它是一种乐趣 - 不变性使得代码更易于推理，并且格式化程序的线程安全性非常有用。
是的，有些文件可以保持最新 - 但至少你可以让它们保持最新状态。这并不是说它们包含了Java内置的东西所不具备的东西，只是使用Java的机制，你只是无法保持时区之类的信息是最新的而没有明显的hackery！
基本上，使用Joda Time的+1。 Java日期/时间API是Java平台中最糟糕的一点，IMO。
答案 1 :(得分：35)
在我看来，Joda-Time最重要的缺点是精度：许多数据库以microsecond（甚至nanosecond）精度存储时间戳。 Joda-time只到milliseconds。这对我来说是不可接受的：我使用的所有“数据模型”类都需要反映数据库中数据的完整精度。图书馆对我的数据的近似或截断不会削减它。
以下是选择毫秒精度的原因，取自JSR 310邮件列表：
“Joda-Time选择使用毫秒，因为它更容易转换为日期和日历。” - S. Colebourne
对谁更容易？图书馆的作者，人们会认为......在我看来，当几乎所有数据库存储时间达到微秒/纳秒精度时，设计决策都是错误的。无视数据库值令人担忧。
答案 2 :(得分：11)
使用Joda Time时遇到的最大问题是与Spring和Tapestry的集成，因为他们都希望使用内置的日期和时间。我们经常在getter / setter中为日期和时间编写包装器：要么将它存储为Joda Time，要么将一组getter / setter传递给它，另一组将动态转换，并且一些类在内部存储为Java日期/时间，Joda getter / setter必须动态切换它。
基本上，这是一个令人头疼的问题，因为这些类的名称相似，除非你可以将整个架构（包括你正在集成的其他库）转换为Joda Time，否则你将编写比你更多的包装代码。可能通过使用Joda库来节省。
答案 3 :(得分：5)
Parleys主持a presentation by Stephen Colebourne about JSR-310，Coledourne先生是Joda-Time和JSR-310的作者。他首先解释了Java中标准日期/时间支持的弱点以及为什么要使用替代方案。向架构管理员展示此演示文稿可能会有所帮助。我似乎无法深层链接
Joda-Time经常更新其时区文件的原因是因为时区数据一直在变化，通常是在短时间内（今天在slashdot：leap second added on 2008-12-31上）而且并不总是科学上的动机（例如我记得一些太平洋岛屿州将其时区改为第一个进入2000年的国家。）
答案 4 :(得分：2)
过去，我遇到的公司不想加入第三方开源软件，或者至少要求公司律师证明许可证不会让他们承担任何责任或对他们的产品产生病毒效应。
与任何第三方库一样，您应该将其放入源代码管理中，以便在出现问题时找到特定版本代码附带的版本。
答案 5 :(得分：2)
基础时间连续体的毫秒选择有利于实现古代日历和特殊日历。与许多计数器不同，64位毫秒计数器具有良好的古代日程覆盖范围，翻转属性超过+/- 2.6亿年。
它不处理闰秒。这是一件好事。原子钟人员提出平滑过渡，以允许没有部署闰秒的系统在100秒内逐步调整其时钟以适应闰秒校正。
维护时区表也是一个问题。
基础连续体还允许一个旧的法国日历和时钟将一天划分为10个间隔，称为度量时间而不是24小时。经典的中国日历将一天分为100个增量，每个长度超过14分钟。所有这些日历都可以在基础毫秒时间连续体上实现和协调。
答案 6 :(得分：0)
它的主要问题是供应商锁定，至少在它成为标准的一部分之前。
在大多数情况下，我会使用long来存储数据库上的任何商业日期信息。这使我可以根据自己的需要灵活调整精度。在大多数情况下，我只是将它们转换为java.util.Date。
时区我认为是演示级问题而不是数据问题。这简化了数据库并提高了可移植性，因为数据库可以用不同的方式表示时间。
标准的Calendar类为我提供了一些日期操作函数，我从epoch数据转换为毫秒。
至于纳秒精度，我会将其作为一个偏移量存储为0作为单独的长列。