为什么我不应该使用date4j而不是joda java.util.Calendar或jsr 310？

Question

我最近遇到了date4j,这是一个非常简单的库(基本上是一个单独的类),用于处理Java中的日期.从概念上讲,我非常喜欢date4j的"想法".实际上,在阅读了整个主站点和javadoc中的文档之后,我几乎同意所说的一切.

现在,可能有几个原因我不应该使用date4j - 错误,性能,缺乏用户等.我不是在问这些事情.从概念上讲,我问的是date4j的概念有什么问题(对于那里的大多数应用程序而言)？当然,可能有一些应用程序需要像joda或threeten这样的东西 - 但我相信这些应用程序属于少数.

人们给处理日期/时间的用户提供的正常建议(几乎所有人都在编写Java应用程序)是这样的:

• 使用joda-time而不是java.util.Calendar
• 将您的Web服务器设置为UTC
• 将数据库服务器设置为UTC
• 将您的日期时间存储在UTC中

实际上,最后三个要点说明了人们在使用日期时当前的心理模型存在的问题.人们试图在应用程序和数据库级别管理时区(更不用说ORM框架添加了另一层抽象,这使得事情变得更加复杂).

你不应该做那些事情.例如,如果您正在使用java.util.Calendar,并且您正在某个用户定义的时区中操作时间:

Calendar c = Calendar.getInstance(TimeZone.getTimeZone("America/New_York"));
c.set(Calendar.YEAR, 2011);
c.set(Calendar.MONTH, 0);
c.set(Calendar.DAY_OF_MONTH, 1);
c.set(Calendar.HOUR_OF_DAY, 3);
c.set(Calendar.MINUTE, 0);
c.set(Calendar.SECOND, 0);
c.set(Calendar.MILLISECOND, 0);

无论时区如何,这都代表了"瞬间".您应该能够将此时间保留在数据库中,而不必担心会发生任何类型的"转换".如果数据库位于上海时区并且网络服务器位于洛杉矶时区也无关紧要 - 无论如何,时刻都是相同的.

一个问题是一些数据库试图为你管理时区(我正在看你,Postgres!grr!)并且更糟糕的是,JDBC驱动程序级别的行为是供应商特定的 - 即PreparedStatement.setDate/getDate.

date4j使用的心理模型似乎摆脱了所有的混乱.例如,显式强制用户在调用now()时提供时区.在网站上有一些非常好的建议来使用这个库(这些我以前在我自己的应用程序中已经做过的事情),例如:

• 不要使用试图管理时区的数据库类型
• 将时区存储为单独的列(如果需要)

为什么没有更多的人采用像date4j这样的图书馆？

Answer 1

我从来没有看过date4j,但是我阅读了文档,我有一个具体的问题,以及一个关于它有什么问题的看法.

一,具体问题.它不会在内部维护时区.所以夏令时含糊不清.考虑周日凌晨1:59:59(美国东部夏令时间)变为凌晨1:00:00(美国东部时间).很明显,在那一天,说凌晨1:30是模棱两可的.那个时间发生了两次.所以以下是模棱两可的

new DateTime("2011-11-06 01:30:00")

第二,我的意见.Date的问题在于它没有维护时区.当Calendar出现时,损坏已经完成.此外,日历本身并没有因为可变而对自己有任何好处.但从本质上讲,解决方案不仅包括时刻,还包括感知时间 - 时区,文化,地区类型的东西.然后,这些需要与持久保存到数据库,序列化,通信等的时刻一起维护.同样的个人原则让我谦卑地建议,即使xsd:dateTime也不合适,因为它只允许相对于UTC表示日期+时间,它没有规定提供是否例如观察夏令时.