Java日期和时间API有什么问题？

啊，Java Date类。最好的例子之一，是如何不以任何语言在任何地方做某事。我从哪里开始？

阅读JavaDoc可能会使人们认为开发人员实际上有了一些好主意。它接着约之间的区别UTC和GMT在长度，尽管两者之间的差别基本上是闰秒（这发生非常 罕见）。

但是，设计决定实际上是在浪费任何被认为是设计良好的API的想法。以下是一些最喜欢的错误：

• 尽管在上个世纪的最后十年进行了设计，但自1900年以来，它的使用年数一直是两位数。由于这个平庸的决定，在Java世界中确实有数百万种变通方法在进行1900+（或1900-）的开发。
• 月是零索引的，以适应具有月数数组且不使用十三元素数组（第一个元素包含）的异常情况null。结果，我们有0..11（今天是109年的第11个月）。为了转换为字符串，在月份中有类似数量的++和-。
• 他们是可变的。因此，任何时候您想要返回一个日期（例如，作为实例结构），都需要返回该日期的副本，而不是日期对象本身（否则，人们可以更改您的结构）。
• 的Calendar，旨在“修复”这一点，实际上使同样的错误。他们仍然是可变的。
• Date代表DateTime，但是为了顺应SQL领域的需求，还有另一个子类java.sql.Date，代表了一天（尽管没有与之关联的时区）。
• 没有TimeZone与关联的Date，因此范围（例如“全天”）通常表示为午夜至午夜（通常在任意时区）

最后，值得注意的是，leap秒通常会根据一个小时后用ntp更新的良好系统时钟进行自我校正（请参见下面的链接）。在引入两个leap跃秒（最少每六个月，实际上每隔几年）的情况下，系统仍无法正常运行的机会，尤其是考虑到必须不时重新部署新版本的代码这一事实。即使使用重新生成类的动态语言或类似WAR引擎的东西，也会污染类空间并最终耗尽permgen。