设置月份为“日历”。MARCH，或者比较，看看它是否== Calendar。比如六月。

Date和Calendar类可以追溯到Java的早期，当时人们还在摸索，它们被广泛认为设计得不是很好。

如果今天用相同的设计创建Calendar，而不是int类型的Calendar。JUNE等等，他们会用枚举。

因为语言写作比看起来要难得多，特别是处理时间比大多数人想象的要难得多。关于这个问题的一小部分(在现实中，不是Java)，请参阅YouTube视频“时间和时区的问题-计算机爱好者”，网址是https://www.youtube.com/watch?v=-5wpm-gesOY。如果你在困惑中笑掉了头，不要感到惊讶。

这只是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个月的日历，这种方法就行不通了……但至少指定的大小是您期望的月数。

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

编辑:作为一个评论，请求一些关于我认为日期/日历错误的想法:

Surprising bases (1900 as the year base in Date, admittedly for deprecated constructors; 0 as the month base in both) Mutability - using immutable types makes it much simpler to work with what are really effectively values An insufficient set of types: it's nice to have Date and Calendar as different things, but the separation of "local" vs "zoned" values is missing, as is date/time vs date vs time An API which leads to ugly code with magic constants, instead of clearly named methods An API which is very hard to reason about - all the business about when things are recomputed etc The use of parameterless constructors to default to "now", which leads to hard-to-test code The Date.toString() implementation which always uses the system local time zone (that's confused many Stack Overflow users before now)

除了DannySmurf关于懒惰的回答之外，我还要补充一句，这是为了鼓励您使用常量，例如Calendar.JANUARY。

它本身并没有定义为0，而是定义为Calendar.January。这是使用整数作为常量而不是枚举的问题。日历。1月== 0。

因为程序员痴迷于基于0的索引。好吧，实际情况要比这复杂一些:当您使用基于0的索引来处理底层逻辑时，它更有意义。但总的来说，我还是会坚持我的第一句话。