“December” conspicuously missing from Android 4.2’s People app

Google's Grinch-like move eliminates Christmas, Hanukkah, Kwanzaa...

According to the Android Police, Android's contacts app in the latest iteration of Jelly Bean only features eleven months out of year. That's right—a side-by-side screenshot on the site shows December conspicuously missing. The People app comes standard with stock Android, but it will not allow users to input December as the birth month of any of their contacts.

The issue has already been reported to the Android bug tracker and was acknowledged by Google yesterday evening. After digging through the Android Open Source Project's (AOSP) code for Android 4.2, Android Police discovered it's really a very minor bug and will only require a little tweaking to fix. It's safe to say Android 4.2.1 will bring back the magic of the December to compatible handsets everywhere. (We figure Google left it out to help us all avoid that Mayan apocalypse ordeal.)

For now, Android 4.2 users can utilize the Calendar app, which recognizes December as the twelfth month of the year. Users can input important dates for events like birthdays and holiday gatherings into the app, though they'll have to do so manually.

Speaking of which, Google, mind slowing releases down? Everyone's still talking about phones getting ICS, Jelly Bean's not even on the radar yet!

I think you're mixing up ICS and JB there, since JB has been out since early this summer.

Regardless, regular small releases allow for better review of the source code (for instance to spot and fix bugs like this) and make it easier to update devices to new ROMs by reducing the amount of drift between source trees. Going back to huge drops that require months to sync like ICS is a terrible idea.

There are now compilers that actually warn you when you do that! That is how common that bug is. Clang makes you wrap it in an extra pair of brackets to make it shut up.

A fantastic solution, in my opinion.

Or Yoda notation for languages that don't complain; always put the constant on the left catches the equality/assignment typo.if (5 = THREAT_LEVEL) would throw an error (or you have a really fun language)

Spoiler: show

Someone will reply saying that Java's final keyword prevents this too (constants and enumerations too)

There are now compilers that actually warn you when you do that! That is how common that bug is. Clang makes you wrap it in an extra pair of brackets to make it shut up.

Yep, it's a good idea - this pattern ("correct" use of this - not the bug pattern) is simply too problematic to use IMO.

Yeah it can be correct to write if (a = b) DoStuff();, but good luck remembering it was intentional years later... letalone the programmer that gets stuck maintaining code they don't really understand. You can comment it sure, but at that point you're not even saving typing over just a = b; if (a) DoStuff();.

I blame the Gregorian calendar. They just couldn't make it more programming friendly, could they?

There should be 8 months, each month should be 32 days long, a day should be 16 hours, each hour should have 64 minutes and each minute should have 64 seconds. Sub seconds are split into 1024 units for each level. This means that you can represent a date and time (to a second) using exactly 24 bits for the actual date, leaving 8 bits for the year. This would unfortunately mean that you would only be able to represent 256 years in a 32bit integer, unless you omitted the date.

Conversions between different units would be easy (unless you want partials), just shift left or right.

Of course, that would make a year 256 days long, so the seasons wouldn't be a yearly phenomenom, instead they would cycle and align every 182,623 years. But who cares about seasons (other than those complaining farmers)?

Actually, it's kinda fun to do the conversions. If we take Gregorian 2000 at 0 in this new calendar, then it would be the year 18 at the moment. My birthday (2nd Jul) would be the 23rd day of the 6th month (23rd of Hexember?), and the binary-encoded version would be 11010110, with the first 3 bits being the month and the next 5 being the day.

Yay calendaring! It's actually kind of amusing that the Gregorian calendar works the way it does. It only has leap years and such because Easter was slipping from spring, and they didn't want that.

Well even if they did, you can still miss something like that quite easily. Assuming that you don't have somebody go through every 365/366 options (especially in a pre-packaged module like a date-picker), then it's easy to miss.

Yeah it can be correct to write if (a = b) DoStuff();, but good luck remembering it was intentional years later... letalone the programmer that gets stuck maintaining code they don't really understand. You can comment it sure, but at that point you're not even saving typing over just a = b; if (a) DoStuff();.

I think there's a fundamental truth of programming in there somewhere.

Well even if they did, you can still miss something like that quite easily. Assuming that you don't have somebody go through every 365/366 options (especially in a pre-packaged module like a date-picker), then it's easy to miss.

Well even if they did, you can still miss something like that quite easily. Assuming that you don't have somebody go through every 365/366 options (especially in a pre-packaged module like a date-picker), then it's easy to miss.

If you put "Does it have all the months?" on a test plan, then you would probably be laughed at and scolded for wasting time.

and now you add it to your tests and boom, it won't be a problem ever again.

tests are not proofs. you will always have bugs.

Oh true, but trying to make the developers out as incompetent (apologies if that wasn't the intention, Gary) isn't very fair. As I've pointed out to other people, bugs like this get through because 1000 bugs that wiped all your data, or texted your entire contact list didn't.

Oh true, but trying to make the developers out as incompetent (apologies if that wasn't the intention, Gary) isn't very fair. As I've pointed out to other people, bugs like this get through because 1000 bugs that wiped all your data, or texted your entire contact list didn't.

I was just poking a little fun. It really should have been noticed in testing, but I can imagine how easily some things are missed. It's a tiny issue, easily fixed in the next patch.

Oh true, but trying to make the developers out as incompetent (apologies if that wasn't the intention, Gary) isn't very fair. As I've pointed out to other people, bugs like this get through because 1000 bugs that wiped all your data, or texted your entire contact list didn't.

I was just poking a little fun. It really should have been noticed in testing, but I can imagine how easily some things are missed. It's a tiny issue, easily fixed in the next patch.

Hence the apology, I realised that it probably wasn't serious while typing that.

On a side note, the people saying about not getting the updates, this kind of update would almost certainly get to everybody affected because it is so small. There is a significant different between going up even a minor version number and getting a patch. 4.2 -> 4.2.1 is like getting a Service Pack, this is a change on the build number, which would go from like (made up) 45629 -> 578143 and you probably wouldn't even notice the update. Also, since this is actually an app-level bug, it should be able to be updated independently of the actual OS.

Florence Ion / Florence was a former Reviews Editor at Ars, with a focus on Android, gadgets, and essential gear. She received a degree in journalism from San Francisco State University and lives in the Bay Area.