Java常用日期时间类库Date与Calendar_技术教程

Date类不能直接用于日期计算，因其设计缺陷：月份从0开始、年份以1900为基点、方法非线程安全且已废弃；Calendar需clear再set字段以防状态残留；新项目应使用Java 8+的不可变、线程安全的java.time API。

Java中Date类为什么不能直接用作日期计算

Date 类在 JDK 1.0 就已存在，但它的大部分方法（如 setYear()、getMonth()、getDate()）从 JDK 1.1 起就被标记为 @Deprecated。这不是因为功能失效，而是设计缺陷：月份从 0 开始（0 表示一月），年份以 1900 为基点（123 表示 2025 年），且所有方法都不是线程安全的。

常见错误现象：

调用 date.getMonth() 返回 0 却误以为是一月以外的月份
用 new Date(2025, 1, 1) 构造对象，结果得到的是 2025 年 2 月 1 日（因年份+1900、月份+1）
多线程环境下共享 Date 实例并调用 setTime()，导致时间值错乱

实际使用中，Date 仅建议作为「时间戳载体」——即只通过 getTime() 获取 long 值，或用构造函数 new Date(long) 初始化。所有业务逻辑中的日期操作，应避免直接调用其已废弃方法。

Calendar类做日期加减时必须先clear再set

Calendar 是 Date 的“补丁式替代”，但它内部状态复杂：字段未显式设置时可能沿用上一次实例的缓存值，尤其在复用同一 Calendar 实例时极易出错。

典型错误写法：

Calendar cal = Calendar.getInstance();
cal.set(Calendar.YEAR, 2025);
cal.add(Calendar.DAY_OF_MONTH, 5); // 你以为是2025-xx-xx加5天？其实可能还是2025年的某天

原因：getInstance() 返回的 Calendar 包含完整当前时间（年月日时分秒毫秒），只调用 set(Calendar.YEAR, 2025) 并不会清空月、日等字段，后续 add() 会在原有基础上叠加。

正确做法：

每次重用前必须调用 cal.clear()
再按需 set() 年、月、日等字段（注意月份仍从 0 开始）
执行 add() 或 roll() 前确保字段已明确初始化

示例：

Calendar cal = Calendar.getInstance();
cal.clear(); // 关键！
cal.set(Calendar.YEAR, 2025);
cal.set(Calendar.MONTH, Calendar.JANUARY); // = 0
cal.set(Calendar.DAY_OF_MONTH, 1);
cal.add(Calendar.DAY_OF_MONTH, 5); // 确保是2025-01-06

Calendar.getTime()返回的Date对象仍是可变的

很多人以为调用 calendar.getTime() 得到一个“快照”后，就可以放心修改原 Calendar。但这个 Date 对象内部只是包装了同一个 long time 值，它本身不隔离状态。

问题在于：Date 的 setTime()、setHours() 等方法依然可用，一旦被意外调用，会污染原始时间语义。

更隐蔽的风险：

将 calendar.getTime() 传给外部方法，而该方法内部调用了 date.setTime(...)
把返回的 Date 存入可变容器（如 ArrayList），之后又对容器中元素调用 setTime()

因此，如果必须返回时间表示，优先考虑：

返回 calendar.getTimeInMillis() 的 long 值（不可变）
或封装成 Instant（Java 8+）：Instant.ofEpochMilli(calendar.getTimeInMillis())
若必须返回 Date，至少做防御性拷贝：n ew Date(calendar.getTimeInMillis())

别再用Date和Calendar处理新项目的时间逻辑

Java 8 引入的 java.time 包（如 LocalDateTime、ZonedDateTime、Duration、Period）已彻底解决上述所有问题：不可变、线程安全、语义清晰、无魔法数字。

迁移成本其实很低：

new Date() → Instant.now()
calendar.get(Calendar.YEAR) → LocalDateTime.now().getYear()
calendar.add(Calendar.MONTH, 1) → localDate.plusMonths(1)

唯一需要警惕的是遗留接口：比如 JDBC 的 PreparedStatement.setDate() 还要求 java.sql.Date。这时应严格遵循转换规范：java.sql.Date.valueOf(localDate) 或 Timestamp.from(instant)，而不是用 new java.sql.Date(date.getTime()) 这种绕过类型语义的写法。

老代码里还藏着 Date 和 Calendar 不代表必须容忍它们——只要涉及日期计算、格式化、时区转换，就该视为技术债立即重构。