It's caused by the convention of the Android datepicker to store month values as 0-11 instead of 1-12.
Dates are given in 1-31 as expected; and years are given in e.g. 2012 as expected; but months are given in 0-11 which is totally inconsistent with how people normally number months and how the rest of the API works.
So for January 1st, 2012, printing 'getDate()', 'getMonth()', and 'getYear()' would yield '1-0-2012'. It's a badly designed API and I'm surprised there aren't more instances of this breaking.
(I ran into this once in our codebase, but we managed to fix it pretty quickly).
You're right, and I didn't doubt that. I meant it's self-inconsistent with how days and years are handled, not necessarily inconsistent with other calendar APIs within Java and Android. Sorry I wasn't clear.
I guess the idea is to use the month as an array index to convert it into a string. You don't usually convert the day of month or the year into a string.
Then declare the array with 13 slots, fill slots 1-12 with the appropriate strings, and don't use slot 0. Or better, put in an error check for being passed a zero.
Suddenly, a 1-12 value for "month" is directly an index into an array to convert the number into a string...
The Java calendar and date APIs are the worst for this and several other design flaws that come back to bite you. There's a reason why JodaTime (http://joda-time.sourceforge.net/) is so popular.
All calendrics APIs will bite you. It's not a property of the API (though I agree Java's is bad) but of the problem domain. The gregorian calendar is simply a mess, and any API on that is just a facade on the mess. Never trust your calendar API. Never fool yourself into thinking you've found the right one. Always be very, very afraid when you find yourself doing arithmetic on a "date".
It's caused by the convention of the Android datepicker to store month values as 0-11 instead of 1-12.
Dates are given in 1-31 as expected; and years are given in e.g. 2012 as expected; but months are given in 0-11 which is totally inconsistent with how people normally number months and how the rest of the API works.
So for January 1st, 2012, printing 'getDate()', 'getMonth()', and 'getYear()' would yield '1-0-2012'. It's a badly designed API and I'm surprised there aren't more instances of this breaking.
(I ran into this once in our codebase, but we managed to fix it pretty quickly).