Java的日期处理是个老大难问题。从1995年诞生至今，这门语言在日期API上栽了三次跟头——前两次要么功能残缺，要么设计反直觉。2014年发布的java.time包本该终结这场闹剧，但一个看似微小的设计选择，让无数开发者在数组索引上踩了同样的坑。
问题很简单：Month枚举的getValue()返回1-12，而ordinal()返回0-11。当你用前者去索引数组时，直接错位一位。
第一次尝试：Date类的"半残"结局
Java 1.0的Date类是个妥协产物。它试图用1970年1月1日以来的毫秒数表达所有时间概念，却忽略了时区、闰秒、历法差异这些现实世界的"杂质"。
更尴尬的是，Date类很快陷入自相矛盾。它的多数方法在Java 1.1中被标记为废弃（deprecated）——不是因为有更好的替代品，而是因为设计本身无法修正。官方文档干脆建议用户转向Calendar，相当于承认第一代方案失败。
这种"半废弃"状态持续了二十多年。直到今天，你仍能在遗留代码里看到new Date()，就像看到博物馆里通电展示的恐龙骨架——能运转，但不该出现在生产环境。
第二次尝试：Calendar的"枚举缺失症"
Java 1.1推出的Calendar类是个进步。它支持时区计算、历法转换、字段操作，至少把日期从简单的毫秒数提升为结构化数据。
但Calendar带着明显的时代烙印：它诞生于1997年，而Java的枚举类型（enum）直到2004年的Java 5才出现。这导致Calendar用一堆int常量表示月份——Calendar.JANUARY=0，Calendar.FEBRUARY=1，以此类推。
0基索引本身不是问题。问题在于Java社区同时存在两种惯例：C系语言倾向0基，而日常表达习惯是1基。当开发者把"1月"写成1而不是0时，bug就诞生了。这种混淆如此普遍，以至于成为Java面试的经典陷阱题。
Calendar的另一个隐痛是线程安全。它的实例可变（mutable），且内部状态复杂，在多线程环境下极易出错。开发者被迫为每次操作新建实例，或依赖ThreadLocal，或忍受同步开销——无论哪种选择，都是API设计欠账的利息。
第三次尝试：java.time的"新旧混血"
Java 8（2014年）彻底重写了日期时间API。JSR 310规范由Stephen Colebourne主导，他此前维护的Joda-Time库已被业界广泛验证。新API的核心设计原则很清晰：不可变对象、明确区分"日期"与"时刻"、链式API设计。
LocalDate是这套体系中最常用的类之一。它剥离了时区，只保留年月日，适合生日、纪念日、合同到期日这类场景。获取月份的方法有两个出口：
• getMonth() 返回Month枚举（如Month.APRIL）
• getMonthValue() 返回int（4）
Month枚举的设计却出现了微妙的分裂。它同时提供两种数值访问方式：getValue()返回1-12，ordinal()返回0-11。官方文档的解释是"getValue()符合ISO-8601标准，其中1月是第1个月"——这听起来合理，直到你开始写数组索引代码。
原文作者Baltasar García演示了典型陷阱：
String[] MESES = {"Enero", "Febrero", ..., "Diciembre"};
MESES[fecha.getMonth().getValue()] // 4月返回"Mayo"（五月）
错误发生得悄无声息。没有编译警告，没有运行时异常，只有错误的数据流向后续逻辑。这种bug在测试阶段极难发现——除非你的测试用例恰好覆盖4月到12月的全部范围。
修正方案是显式减1：MESES[fecha.getMonth().getValue() - 1]。或者改用ordinal()，但后者在枚举重排序时会失效（尽管Month的月份顺序不太可能改变）。
设计选择的代价：一致性 vs. 直觉
为什么getValue()不直接返回0-11？官方理由是ISO-8601符合性。该国际标准明确将1月编码为1，12月为12，Java选择遵循这一惯例。
但代价是破坏了与Java数组索引的兼容性。Java作为语言，数组和集合全面采用0基索引。当日期API选择1基时，两种惯例在每个数组访问点发生冲突。这不是技术缺陷，是设计权衡的必然结果——只是这个代价由每个写MESES[month]的开发者承担。
对比其他语言的做法更有意思。Python的datetime.month返回1-12，但Python列表支持负数索引，且社区更习惯显式字典映射而非数组索引。C#的DateTime.Month同样返回1-12，但.NET的数组访问场景相对较少。Java的特殊性在于：它同时强推枚举类型、保持数组核心地位、又在日期API中引入1基数值——三股力量交汇，形成了这个特定陷阱。
一个细节值得玩味：Month枚举的ordinal()方法返回0-11，与Calendar的月份常量一致。这意味着Java内部存在两套并行惯例：面向标准的getValue()，面向索引的ordinal()。这种"双轨制"让开发者必须时刻清醒自己在用哪条轨道。
时区：悬在头顶的达摩克利斯之剑
日期API的复杂性不止于索引偏移。全球时区规则处于持续变动中：政治体更换时区、夏令时政策调整、甚至整国取消或恢复夏令时。2018年朝鲜取消夏令时，2024年墨西哥部分地区调整时区，这些变化都要求JDK发布补丁更新。
java.time通过ZoneId和ZoneOffset将时区逻辑外置，比Calendar的硬编码时区表更灵活。但"灵活"不等于"简单"。当开发者调用ZonedDateTime.now()时，背后触发的是tzdata数据库查询、规则匹配、偏移计算——任何环节的版本滞后都会导致错误时刻。
Oracle维护的时区数据更新与JDK版本绑定。这意味着生产环境可能运行着包含过时tzdata的JVM，而开发者对此毫无察觉。2019年巴西取消夏令时的紧急补丁，就曾让未及时更新JDK的系统陷入混乱。
第四次尝试已在路上？
原文作者在2026年4月写下这段分析时，已经预见了结局："spoiler: seguirá teniendo defectos, y se planteará una nueva alternativa"（剧透：仍会有缺陷，并将提出新替代方案）。
这不是悲观，是历史规律的总结。Date、Calendar、java.time——每一代方案都解决了前代的核心痛点，又引入新的设计债务。日期时间本质上是人类社会的混沌映射到计算机的确定性系统，任何抽象都有泄漏点。
Valhalla项目（Java值类型）和Lilliput项目（对象头压缩）可能在底层改变日期对象的内存布局，但API层面的第四次重写尚未列入官方路线图。更可能的演进是渐进式改进：增加新的日历系统支持、优化时区数据加载性能、或者——最务实的——在Month枚举文档中加粗警告"getValue()不适用于数组索引"。
一个来自Stack Overflow的2015年提问记录了这个bug的持久生命力：开发者困惑于为什么Month.APRIL.getValue()返回4却索引到错误位置，回答者解释这是"by design"。该问题至今每年仍有新评论，成为Java日期API的"活化石"标本。
你最后一次写MESES[month.getValue()]是什么时候发现的错位？是单元测试报红，还是生产日志里的异常数据，或是代码审查时同事的冷汗表情？
热门跟贴