为什么阿里开发手册不建议使用Date类？

在日常编码中，基本上99%的项目都会有一个DateUtil工具类，而时间工具类里用的最多的就是java.util.Date。

大家都这么写，这还能有问题？？

当你的“默认常识”出现问题，这个打击，就是毁灭性的。

但是，在进行安全扫描的时候，提示java.util.Date存在安全漏洞。

👉 GPT功能：

1. GPT-4o知识问答：支持1000+token上下文记忆功能
2. 最强代码大模型Code Copilot：代码自动补全、代码优化建议、代码重构等
3. DALL-E AI绘画：AI绘画 + 剪辑 = 自媒体新时代
4. 私信哪吒，直接使用GPT-4o

public class DateUtil {/*** 日期格式化*/public static String formatDate(Date date, String format) {SimpleDateFormat sdf = new SimpleDateFormat(format);return sdf.format(date);}/*** 字符串转Date*/public static Date parseDate(String dateStr, String format) throws ParseException {SimpleDateFormat sdf = new SimpleDateFormat(format);return sdf.parse(dateStr);}/*** 获取指定格式的当前时间*/public static String getCurrentDate(String format) {// 获取当前时间Date currentDate = new Date();// 定义日期格式SimpleDateFormat dateFormat = new SimpleDateFormat(format);return dateFormat.format(currentDate);}
}

把组件风险列表截图+DateUtil工具类发给我的编程小助手ChatGPT4o。

Prompt：在进行安全扫描的时候，提示java.util.Date存在安全漏洞，有什么漏洞，如何解决？

import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;
import java.time.LocalDate;
import java.time.LocalTime;
import java.time.ZoneId;
import java.util.Date;public class DateUtil {// 日期格式化public static String formatDate(LocalDateTime dateTime, String format) {DateTimeFormatter formatter = DateTimeFormatter.ofPattern(format);return dateTime.format(formatter);}// 字符串转Datepublic static LocalDateTime parseDate(String dateStr, String format) {DateTimeFormatter formatter = DateTimeFormatter.ofPattern(format);return LocalDateTime.parse(dateStr, formatter);}// 获取指定格式的当前时间public static String getCurrentDate(String format) {// 获取当前时间LocalDateTime currentDate = LocalDateTime.now();// 定义日期格式DateTimeFormatter dateFormat = DateTimeFormatter.ofPattern(format);return currentDate.format(dateFormat);}// 将 java.util.Date 转为 java.time.LocalDateTimepublic static LocalDateTime convertToLocalDateTime(Date date) {return LocalDateTime.ofInstant(date.toInstant(), ZoneId.systemDefault());}// 将 java.time.LocalDateTime 转为 java.util.Datepublic static Date convertToDate(LocalDateTime dateTime) {return Date.from(dateTime.atZone(ZoneId.systemDefault()).toInstant());}
}

以下是Date设计上的主要缺陷：

1、Date 这个名称本身就具有误导性。它实际上表示的是一个时间点，而非日期。因此，更为恰当的名称应为 Instant，这与 java.time 中的对应类型相符。

2、它不是一个最终类，这导致了诸如 java.sql.Date 等不良的继承使用。java.sql.Date 旨在表示一个日期，但由于名称相同而常常引起混淆。

3、Date 是可变的，而日期/时间类型通常是自然值，适合用不可变类型进行建模。Date 的可变性（例如通过 setTime 方法）迫使开发人员不得不创建大量防御性副本，以确保代码的安全性。

4、Date 在许多地方（包括 toString() 方法）隐式使用系统本地时区，这常常让开发人员感到困惑。更多细节可以参见“时间点是什么”部分。

5、Date 的月份编号从 0 开始，这是借鉴自 C 语言的设计。这种设计导致了大量的“偏一”错误。同样，年份编号从 1900 开始，也是借鉴自 C 语言。显然，当 Java 出现时，我们已经意识到这种设计不利于代码的可读性。

6、Date 的方法命名也不清晰。getDate() 方法返回的是月中的某一天，而 getDay() 方法返回的是星期几。给这些方法起更具描述性的名称并不会很困难，但遗憾的是，这并未实现。

7、对于是否支持闰秒，Date 的表现也不明确。文档中指出“一秒钟由一个 0 到 61 的整数表示；60 和 61 仅在实际正确跟踪闰秒的 Java 实现中出现。” 我强烈怀疑，大多数开发人员（包括我自己）都默认认为 getSeconds() 方法的返回值范围是 0-59。

8、Date 类的方法对参数范围的要求非常宽松，这没有明显的理由。例如，方法允许日期参数为 1 月 32 日，并解释为 2 月 1 日。这种宽松的参数范围在实际应用中并不常见，反而增加了使用的复杂性和出错的风险。

尽管还能找到更多的问题，但那会显得过于挑剔。

👉 GPT功能：

1. GPT-4o知识问答：支持1000+token上下文记忆功能
2. 最强代码大模型Code Copilot：代码自动补全、代码优化建议、代码重构等
3. DALL-E AI绘画：AI绘画 + 剪辑 = 自媒体新时代
4. 私信哪吒，直接使用GPT-4o