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...
views:
3136answers:
11
+4
A:
I'd say laziness. Arrays start at 0 (everyone knows that); the months of the year are an array, which leads me to believe that some engineer at Sun just didn't bother to put this one little nicety into the Java code.
DannySmurf
2008-12-05 16:25:13
you may call it efficiency.
Milhous
2008-12-05 16:31:40
No, I wouldn't. It is more important to optimize the efficiency of one's customers than one's programmers. Since this customer is spending time here asking, they failed at that.
DannySmurf
2008-12-05 16:45:42
It's totally unrelated to efficiency — it's not as if months are stored in an array and you'd need 13 to represent 12 months. It's a matter of not making the API as user-friendly as they should have been in the first place. Josh Bloch rags on Date and Calendar in "Effective Java". Very few APIs are perfect, and the date/time APIs in Java have the unfortunate role of being the ones that were goofed. That's life, but let's not pretend it has anything to do with efficiency.
Quinn Taylor
2009-08-11 03:06:51
+4
A:
Because programmers are obsessed with 0-based indexes. OK, it's a bit more complicated than that: it makes more sense when you're working with lower-level logic to use 0-based indexing. But by and large, I'll still stick with my first sentence.
Dinah
2008-12-05 16:26:02
This is another of those idioms/habits that go _way_ back to assembler or machine language where everything is done in terms of offsets, not indexes. Array notation became a short cut for accessing contiguous blocks, starting at offset 0.
Ken Gentle
2008-12-05 17:56:16
+1
A:
Indexes are zero based in Java.
A calendar is basically an array of months, so it would be inconsistent to start at anything else as all other arrays begin at 0.
Stevo
2008-12-05 16:26:46
You should have said "String-based indexes are zero based." Solves the above complaint ;-)
JoshFinnie
2008-12-05 19:18:08
I must disagree that it would be inconsistent to not be zero-based. (Have you ever considered representing New Years' as "2009-00-01"?) If one makes an argument for consistency, shouldn't days of the month also be zero-based, and run from 0 to 27|29|30 instead? The critical flaw in your argument is starting from the assumption that "a calendar is basically an array of months". You may be able to represent it as such, but the end result will never be elegant or sufficiently user-friendly. At least we have defined constants, but even that is needlessly verbose. I say bring on the new API.
Quinn Taylor
2009-08-11 03:13:51
+1
A:
In addition to DannySmurf's answer of laziness, I'll add that it's to encourage you to use the constants, such as Calendar.JANUARY.
R. Bemrose
2008-12-05 16:27:01
That's all very well when you're explicitly writing the code for a particular month, but it's a pain when you've got the month in "normal" form from a different source.
Jon Skeet
2008-12-05 17:11:00
+28
A:
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 - which is the basis for the new API in Java 7. Much nicer.
Jon Skeet
2008-12-05 16:29:41
...and what's up with deprecating all the useful simple Date methods? Now I have to use that horrible Calendar object in complicated ways to do things that used to be simple.
Brian Knoblauch
2008-12-05 17:22:48
@Brian: I feel your pain. Again, Joda Time is simpler :) (The immutability factor makes things so much more pleasant to work with, too.)
Jon Skeet
2008-12-05 17:26:16
+9
A:
More important: if months are counted from 0 (and they are), why are days counted from 1?
Bombe
2008-12-05 16:30:37
Inconsistent though it may be, the days already have "indexes" assigned to them.
sblundy
2008-12-05 16:34:31
+14
A:
C based languages copy C to some degree. The tm structure (defined in time.h) has an integer field tm_mon with the (commented) range of 0-11.
C based languages start arrays at index 0. So this was convenient for outputting a string in an array of month names, with tm_mon as the index.
stesch
2008-12-05 16:35:42
+2
A:
Personally, I took the strangeness of the Java calendar API as an indication that I needed to divorce myself from the Gregorian-centric mindset and try to program more agnostically in that respect. Specifically, I learned once again to avoid hardcoded constants for things like months.
Which of the following is more likely to be correct?
if (date.getMonth() == 3) out.print("March");
if (date.getMonth() == Calendar.MARCH) out.print("March");
This illustrates one thing that irks me a little about Joda Time - it may encourage programmers to think in terms of hardcoded constants. (Only a little, though. It's not as if Joda is forcing programmers to program badly.)
Paul Brinkley
2008-12-05 17:09:57
But which scheme is more likely to give you a headache when you don't have a constant in your code - you have a value which is the result of a web service call or whatever.
Jon Skeet
2008-12-05 17:28:18
That web service call should also be using that constant, of course. :-) Same goes for any external caller. Once we've established that multiple standards exist, the need to enforce one becomes evident. (I do hope I understood your comment...)
Paul Brinkley
2008-12-05 18:59:59
Yes, we should enforce the standard that almost everything else in the world uses when expressing months - the 1-based standard.
Jon Skeet
2008-12-05 19:20:14
The key word here being "almost". Obviously, Jan=1, etc. feels natural in a date system with extremely wide use, but why allow ourselves to make an exception to avoiding hardcoded constants, in even this one case?
Paul Brinkley
2008-12-05 21:34:24
Because it makes life easier. It just does. I have *never* encountered an off-by-one problem with a 1-based month system. I've seen *plenty* such bugs with the Java API. Ignoring what everyone else in the world does just makes no sense.
Jon Skeet
2008-12-06 07:33:01
I sympathize; though I don't do very large amounts of Java date programming, I've never run into an off-by-one problem either, in any other language. The only thing that bugs me here is the hardcoded-ness of it.
Paul Brinkley
2008-12-08 21:05:33
+5
A:
In Java 7, we should have a new Date/Time API JSR 310 that is more sane. The spec lead is the same as the primary author of JodaTime and they share many similar concepts and patterns.
UPDATE: Sadly, it looks like JSR 310 will not make it into Java 7.
Alex Miller
2008-12-05 19:25:22
A:
It isn't exactly defined as zero per se, it's defined as Calendar.January. It is the problem of using ints as constants instead of enums. Calendar.January == 0.
Pål GD
2008-12-06 14:32:11
The values are one and the same. The APIs may as well return 0, it's identical to the constant. Calendar.JANUARY could have been defined as 1 — that's the whole point. An enum would be a nice solution, but true enums weren't added to the language until Java 5, and Date has been around since the beginning. It's unfortunate, but you really can't "fix" such a fundamental API once third-party code uses it. The best that can be done is to provide new API and deprecate the old one to encourage people to move on. Thank you, Java 7...
Quinn Taylor
2009-08-11 03:20:21