因为用月份计算要简单得多。

12月之后的一个月就是1月，但是要算出这个，通常你需要用月份的数字来计算

12 + 1 = 13 // What month is 13?

我知道!我可以通过使用模量12来快速解决这个问题。

(12 + 1) % 12 = 1

在11月之前的11个月里，这一切都很好……

(11 + 1) % 12 = 0 // What month is 0?

你可以在加上月份之前再减去1，然后做模数，最后再加1……也就是解决潜在的问题。

((11 - 1 + 1) % 12) + 1 = 12 // Lots of magical numbers!

现在让我们考虑0 - 11月的问题。

(0 + 1) % 12 = 1 // February
(1 + 1) % 12 = 2 // March
(2 + 1) % 12 = 3 // April
(3 + 1) % 12 = 4 // May
(4 + 1) % 12 = 5 // June
(5 + 1) % 12 = 6 // July
(6 + 1) % 12 = 7 // August
(7 + 1) % 12 = 8 // September
(8 + 1) % 12 = 9 // October
(9 + 1) % 12 = 10 // November
(10 + 1) % 12 = 11 // December
(11 + 1) % 12 = 0 // January

所有月份的工作都是一样的，没有必要进行变通。

可能是因为C的“struct tm”也有同样的功能。

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

There has been a lot of answers to this, but I will give my view on the subject anyway. The reason behind this odd behavior, as stated previously, comes from the POSIX C time.h where the months were stored in an int with the range 0-11. To explain why, look at it like this; years and days are considered numbers in spoken language, but months have their own names. So because January is the first month it will be stored as offset 0, the first array element. monthname[JANUARY] would be "January". The first month in the year is the first month array element.

另一方面，由于日期数字没有名称，将它们存储在0-30的int型中会令人困惑，添加大量的day+1指令用于输出，当然，也容易出现很多错误。

也就是说，这种不一致是令人困惑的，特别是在javascript(它也继承了这个“特性”)中，这种脚本语言应该从语言中抽象出来。

因为月份有名称，而月份中的日期没有。

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

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

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

我想说是懒惰。数组从0开始(每个人都知道);一年中的月份是一个数组，这让我相信Sun的一些工程师只是懒得在Java代码中加入这个小细节。