它只是Java日期/时间API的一团糟。列出问题所在将花费很长时间（而且我确定我不知道其中一半是问题）。诚然，处理日期和时间是很棘手的，但是无论如何都是这样。
帮个忙，改用Joda Time或JSR-310。
编辑：至于原因-如其他答案所述，这很可能是由于旧的C API引起的，或者只是从0开始一切的一般感觉…当然，除了日子从1开始。我怀疑最初的实施团队之外的人是否真的可以说出原因-但是，我再次敦促读者不要太担心为什么会做出错误的决定，而要全神贯注地java.util.Calendar寻找更好的东西。
一个点，这是赞成使用基于0的索引的是，它使事情变得像“名字的阵列”更容易：
// I "know" there are 12 monthsString[] 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()
它总是使用系统本地时区（即现在来迷惑许多堆栈溢出用户之前）执行
