一尘不染

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

python

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

有人能对此有所启发吗?


阅读 361

收藏
2020-02-24

共1个答案

一尘不染

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

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

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

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

最后,值得注意的是,leap秒通常会在一个小时之内用ntp更新的良好系统时钟纠正自身(请参见下面的链接)。在引入两个leap跃秒(最少每六个月,实际上每隔几年)的情况下,系统仍然可以运行的可能性非常小,尤其是考虑到必须不时重新部署新版本的代码这一事实。即使使用重新生成类或诸如WAR引擎之类的动态语言,也会污染类空间并最终耗尽permgen。

2020-02-24