它只是 Java 日期/时间 API 的可怕混乱的一部分。列出它的问题需要很长时间（而且我确信我不知道一半的问题）。诚然，处理日期和时间很棘手，但无论如何。

帮自己一个忙，改用Joda Time或JSR-310。

编辑：至于原因 - 正如其他答案中所述，这很可能是由于旧的 C API，或者只是从 0 开始的一般感觉......当然，除了那些日子从 1
开始。我怀疑原始实施团队之外的任何人是否真的能说明原因 - 但我再次敦促读者不要太担心 为什么
会做出错误的决定，而是要看看整个肮脏的范围java.util.Calendar并找到更好的东西。

支持使用基于 0 的索引的一点 是 ，它使诸如“名称数组”之类的事情变得更容易：

// I "know" there are 12 months
String[] monthNames = new String[12]; // and populate...
String name = monthNames[calendar.get(Calendar.MONTH)];

当然，一旦你得到一个 13 个月的日历，这就会失败......但至少指定的大小是你期望的月数。

这不是一个 好 理由，但这是 一个 理由......

编辑：作为评论请求一些关于我认为日期/日历有问题的想法：

• 令人惊讶的基数（1900 作为 Date 的年基，不可否认的是已弃用的构造函数；0 作为两个月的基数）
• 可变性——使用不可变类型可以 更 简单地处理真正有效的 值
• 类型集不足：拥有Date和Calendar作为不同的东西很好，但是缺少“本地”与“分区”值的分离，日期/时间与日期与时间也是如此
• 一个 API 会导致带有魔法常量的丑陋代码，而不是明确命名的方法
• 一个很难推理的 API - 关于何时重新计算事物等的所有业务
• 使用无参数构造函数默认为“现在”，这导致代码难以测试
• 始终使用系统本地时区的Date.toString()实现