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".
I wonder if there's been any movement on the dreadful performance of 4.2? It made me very aware that there is little to no support for Android/Nexus, and nowhere to take problems unless you know what a bug tracker is, which many will not.
That's curious. 8 or 16GB? I haven't run into it myself, but I've heard that low free space will slow down the Nexus 7.
Stuff like better animations for the app switcher made my own Nexus 7 feel faster after the 4.2 update. Of course, that's just a perceptual change.
Prior to 4.2, Chrome with many tabs open and Adobe Reader were my only major annoyances. Chrome seems somewhat better, though since I've cut down on tab usage and started using Firefox more I'm not sure how much it's really improved. As for Reader, I just use ezPDF for larger documents now.
The lag can be unbearable at times. Makes my HP touchpad running CM feel fast. I've had some luck shutting down processes in Settings->Apps. An XDA member reported that his performance and battery life improved after cycling the battery a couple of times.
It's rather ironic that a company so high-tech it's looking hard at self-driving cars and asteroid mining has trouble implementing a calendar, a technology that's been around for thousands of years...
You've made a good point. It's not as if built-in Android apps aren't important to Google, or they don't have a release process. I think heads will roll over this.
just people they are so technical savvy doesn't mean they don't make mistakes. tests aren't perfect. you can't spend every day to write all corner cases. i don't consider that as ironic. i consider it as normal. users are so willing to help the software moving. that's the spirit of android software being open-source. we can find such small bug quickly and the engineers can fix this bug soon.
Have they? I thought the only crash was when a person in a car crashed into the back of one? (pretty sure the self-driving car was being driven by a person at that point too).
That statement will almost certainly be true at some point, but thus far my understanding is Google's self-driving cars have not caused an accident yet.
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).