为什么现在Java连Date类都不建议使用了

有什么问题吗java.util.Date？

java.util.Date（Date从现在开始）是一个糟糕的类型，这解释了为什么它的大部分内容在 Java 1.1 中被弃用（但不幸的是仍在使用）。

设计缺陷包括：

• 它的名称具有误导性：它并不代表 a Date，而是代表时间的一个瞬间。所以它应该被称为Instant——正如它的java.time等价物一样。

• 它是非最终的：这鼓励了对继承的不良使用，例如java.sql.Date（这意味着代表一个日期，并且由于具有相同的短名称而也令人困惑）

• 它是可变的：日期/时间类型是自然值，可以通过不可变类型有效地建模。可变的事实Date（例如通过setTime方法）意味着勤奋的开发人员最终会在各处创建防御性副本。

• 它在许多地方（包括）隐式使用系统本地时区，toString()这让许多开发人员感到困惑。有关此内容的更多信息，请参阅“什么是即时”部分

• 它的月份编号是从 0 开始的，是从 C 语言复制的。这导致了很多很多相差一的错误。

• 它的年份编号是基于 1900 年的，也是从 C 语言复制的。当然，当 Java 出现时，我们已经意识到这不利于可读性？

• 它的方法命名不明确：getDate()返回月份中的某一天，并getDay()返回星期几。给这些更具描述性的名字有多难？

• 对于是否支持闰秒含糊其辞：“秒由 0 到 61 之间的整数表示；值 60 和 61 仅在闰秒时出现，即使如此，也仅在实际正确跟踪闰秒的 Java 实现中出现。” 我强烈怀疑大多数开发人员（包括我自己）都做了很多假设，认为 for 的范围getSeconds()实际上在 0-59 范围内（含）。

• 它的宽容没有明显的理由：“在所有情况下，为这些目的而对方法给出的论据不必落在指定的范围内; 例如，日期可以指定为 1 月 32 日，并被解释为 2 月 1 日。” 多久有用一次？

更多细节内容参考：https://t.zsxq.com/18HLAb2hI。

为啥要改？

我们要改的原因很简单，我们的代码缺陷扫描规则认为这是一个必须修改的缺陷，否则不给发布，不改不行，服了。

解决思路：避免使用java.util.Date与java.sql.Date类和其提供的API，考虑使用java