Java日期处理历史：从Date到Calendar的变量混乱

Ja va早期日期处理的核心问题，可以概括为“一个类干太多事，又干得不直观”。Date类的本意是表示一个时间点，却暴露了年月日等字段操作接口；Calendar类本想补足Date的短板，结果自己又堆砌了大量易错常量和可变状态。这种设计导致开发者频繁掉坑，不是月份算错，就是时区偏移，其根源就在于变量职责不清、状态可以随意变更。

Date类：名字误导与字段反直觉

Date这个名字极具迷惑性，表面叫“日期”，实际上它只是一个毫秒时间戳的包装器。它内部并不存储年月日，只存储自1970年1月1日0时（GMT）以来的long型毫秒值。然而，它早期提供的方法却强行暴露了日期语义，这带来了诸多反直觉的设计：

• getYear() 返回的是“年份减1900”，例如2026年会返回126。
• getMonth() 从0开始计数，1月是0，12月是11。
• getDate() 这个名字听起来像“获取日期对象”，实际是“获取月中的日（day of month）”，极易与后来ja va.time包中的LocalDate概念混淆。
• 所有这些方法如今都已标记为@Deprecated，但在历史遗留项目中仍随处可见，重构成本不菲。

Calendar类：补位者反而带来了更多混乱

为了弥补Date的不足，Calendar应运而生。它本应是Date的增强版，但其采用的抽象类加静态工厂模式，却引入了新的复杂度：

• 必须通过Calendar.getInstance()获取实例，其背后默认绑定系统时区，形成对运行环境的隐式依赖。
• 所有字段操作都依赖整数常量，如Calendar.MONTH、Calendar.DAY_OF_YEAR等。一旦写错常量名或传错值，编译器很难发现。
• set()方法存在多个重载版本，例如set(year, month, date)和set(field, value)。混用时极易遗漏设置时分秒，导致时间部分被意外重置为00:00:00。
• get()和set()操作并非原子性的。修改年份后，如果没有调用getTime()等方法触发重新计算，后续的get操作可能返回未同步的中间状态。

变量混乱的典型表现

这些问题往往不是简单的代码笔误，而是底层模型设计上的矛盾所导致的：

• 可变性泛滥：Date和Calendar对象都可以被随时修改。在方法间传递参数时，开发者不敢直接共享对象引用，总担心被上游或下游代码意外改动。
• 时区藏得太深：Date.toString()方法会按照本地时区格式化输出，但getTime()方法返回的却是基于UTC的毫秒值。这导致同一个对象，打印出来的结果和用于计算的值看起来可能不一致。
• 日期与时间无法解耦：如果只想处理“2026-05-10”这个纯日期概念？很遗憾，Date和Calendar都强制携带时间部分。即便你只设置了年月日，其内部的时分秒也会被默认设置为当前时刻或零值。
• 线程安全真空：旧API没有内置任何同步机制。多线程环境下共享同一个Calendar实例时，get和set操作交叉执行，极易导致内部字段状态错乱，例如年份显示为2026，月份却停留在上一次设置的值（比如2，代表三月）。

为什么迁移到ja va.time是必要选择

推动迁移的核心原因，并非旧API完全无法使用，而是它将本应由类型系统来保证的规则，完全交给了开发者凭记忆和自觉去遵守。相比之下，ja va.time包的设计清晰得多：

• LocalDate 只负责日期，不包含时间，构造后即不可变。
• LocalDateTime 明确表示“本地日期时间”，不涉及时区转换。
• ZonedDateTime 将时区作为一等公民，时区ID、偏移量、夏令时转换规则都被显式地建模出来。
• 所有核心类都是final且不可变的，这使得它们在方法传参、缓存以及并发场景下使用都无需担心副作用。