它只是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个月的日历，此操作就会失败…但是至少指定的大小是你期望的月数。

这不是一个很好的理由，但这是一个理由…

编辑：作为一种评论，它要求我对Date / Calendar错误的一些想法：

• 令人惊讶的基数（Date中的1900作为Date中的年基，已弃用的构造函数必不可少；两者均为月基）
• 可变性-使用不变类型使得很多简单的什么是真正有效的工作值
• 类型集不足：拥有Date和Calendar作为其他事物很好，但是缺少“本地”值与“分区”值的分隔，日期/时间与日期对时间也是如此
• 一个使用魔术常数导致丑陋代码的API，而不是使用明确命名的方法
• 很难推理的API-有关何时重新计算事物的所有事务等
• 使用无参数的构造函数默认为“ now”，这导致难以测试的代码
• 在Date.toString()它总是使用系统本地时区（即现在来迷惑许多堆栈溢出用户之前）执行