它只是可怕的混亂的一部分，即JavaDate/TimeAPI。列出問題所在需要很長時間(我肯定我不知道其中一半的問題)。誠然，處理日期和時間是很棘手的，但是無論如何。
幫自己個忙，好好利用Joda時間相反，或者可能JSR-310.
編輯：至于為什么-正如在其他答案中所指出的，這很可能是由于舊的C API，或者僅僅是一種從0開始所有事情的普遍感覺.當(dāng)然，那一天從1開始。我懷疑在最初的實現(xiàn)團隊之外的人是否真的能說明原因，但我再次敦促讀者不要太擔(dān)心。為什么我們做出了錯誤的決定，看了看java.util.Calendar找點更好的。
有一點是贊成使用基于0的索引是因為它使諸如“名稱數(shù)組”這樣的事情變得更容易：
// I "know" there are 12 monthsString[] monthNames = new String[12]; // and populate...String name = monthNames[calendar.get(Calendar.MONTH)];
當(dāng)然，一旦你拿到有13個月的日歷，這就失敗了.但至少指定的大小是您預(yù)期的月數(shù)。
這不是好的原因，但這是.a理由.。
編輯：作為一種評論，詢問一些關(guān)于我認(rèn)為日期/日歷有什么問題的想法：
- 令人驚訝的基數(shù)(1900年為日期的年份基數(shù)，不可否認(rèn)為不推薦的構(gòu)造函數(shù)；0作為兩個年份的月份基數(shù))
- 可變性-使用不可變類型使其
多
更簡單地處理真正有效的東西價值
- 一組不夠的類型：擁有
Date
和Calendar
作為不同的事物，但是“本地”與“分區(qū)”值的分離以及日期/時間與時間的分離是缺失的。 - 一個API，它導(dǎo)致使用神奇常量的丑陋代碼，而不是明確命名的方法。
- 一個很難推理的API-所有關(guān)于什么時候被重新計算的業(yè)務(wù)等等。
- 使用無參數(shù)構(gòu)造函數(shù)默認(rèn)為“Now”，這將導(dǎo)致硬測試代碼。
- 這個
Date.toString()
實現(xiàn)，它總是使用系統(tǒng)本地時區(qū)(這使以前許多堆棧溢出用戶感到困惑)
