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

Question

我经常遇到对 Java Date 和其他与日期时间相关的类的负面反馈。作为 .NET 开发人员，我不能完全(没有使用过它们)理解它们到底有什么问题。

有人能解释一下吗？

Answer 1

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

阅读 JavaDoc 可能会让人认为开发人员实际上已经有了一些好主意。继续讨论 UTC 之间的区别和 GMT最后，尽管两者之间的差异基本上是闰秒(发生 pretty rarely)。

但是，设计决策确实浪费了任何作为设计良好的 API 的想法。以下是一些最常见的错误:

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

最后，值得注意的是，闰秒通常会在一个小时内使用 ntp 更新的良好系统时钟进行 self 校正(参见上面的链接)。在引入两个闰秒(最少每六个月，实际上每几年)后系统仍然启动并运行的可能性非常小，尤其是考虑到您必须不时重新部署新版本代码的事实.即使使用重新生成类的动态语言或类似 WAR 引擎的东西也会污染类空间并最终耗尽 permgen。