为什么1月月份在Java日历0？ [英] Why is January month 0 in Java Calendar?

问题描述

在 java.util.Calendar 中，一月定义为月0，而不是月1.有什么具体原因吗？

我看到很多人对此感到困惑...

解决方案

这只是可怕的一部分mess是Java日期/时间API。列出什么问题，它需要很长的时间（我相信我不知道一半的问题）。不可否认，处理日期和时间是件棘手的事，但仍然是aaargh。

自己动手，使用 Joda时间，或者可能 JSR-310 。 / p>

编辑：至于为什么 - 如在其他答案中指出，它可能是由于老的C API，或者只是一个普遍的感觉，启动一切从0 ..除了那些天从1开始，当然。我怀疑原始实施团队之外的任何人是否真的可以说明理由 - 但是，我再次敦促读者不要为了为什么做错误决定而担心，因为看看整个全域的 $ 赞成使用基于0的索引是它使得像名称数组这样的事情更容易：

  //我知道有12个月
 String [] monthNames = new String [12]; // and populate ... 
 String name = monthNames [calendar.get（Calendar.MONTH）]; 
  

当然，只要您获得了13个月的日历...指定的大小是您期望的月数。

这不是好的原因，而是 >原因...

编辑：作为一个评论类请求一些想法，我认为是错误的日期/日历：

• 令人惊讶的基地（1900年作为年底，承认用于已弃用的构造函数; 0作为月底）


• 使用不可变类型使得更容易使用真正有效的值。


• 一组不足的类型： 日期和日历为不同的东西，
  ，但本地缺少，日期/时间vs日期vs时间


• 一个API，它使用魔法常量而不是明确命名的方法生成丑陋的代码


• API非常难以推理 - 关于何时重新计算事物的所有业务等


• 使用无参数构造函数来默认为now，这导致难以测试的代码 $ Date.toString（）实现，它总是使用系统本地时区（这使得很多Stack Overflow用户感到困惑） / li>


In java.util.Calendar, January is defined as month 0, not month 1. Is there any specific reason to that ?

I have seen many people getting confused about that...

解决方案

It's just part of the horrendous mess which is the Java date/time API. Listing what's wrong with it would take a very long time (and I'm sure I don't know half of the problems). Admittedly working with dates and times is tricky, but aaargh anyway.

Do yourself a favour and use Joda Time instead, or possibly JSR-310.

EDIT: As for the reasons why - as noted in other answers, it could well be due to old C APIs, or just a general feeling of starting everything from 0... except that days start with 1, of course. I doubt whether anyone outside the original implementation team could really state reasons - but again, I'd urge readers not to worry so much about why bad decisions were taken, as to look at the whole gamut of nastiness in java.util.Calendar and find something better.

One point which is in favour of using 0-based indexes is that it makes things like "arrays of names" easier:

// I "know" there are 12 months
String[] monthNames = new String[12]; // and populate...
String name = monthNames[calendar.get(Calendar.MONTH)];

Of course, this fails as soon as you get a calendar with 13 months... but at least the size specified is the number of months you expect.

This isn't a good reason, but it's a reason...

EDIT: As a comment sort of requests some ideas about what I think is wrong with Date/Calendar:

• 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)

这篇关于为什么1月月份在Java日历0？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！