a while ago, i noticed that the iPhone contacts app is not smart enough to properly handle birthdays, because it always requires years and thus only supports birthdates (and not birthdays). that was an inconvenience, but at least one that could be worked around by always using some fake year for birthdays with unknown years (and the birthday app i am using on the iPhone even supports handling one specific fake year as an unknown year of birth).
recently, i ran into another problem with the date handling of the contacts apps, and this time it is is more than an inconvenience, because date handling seems to be broken on a conceptual level. what happened is that i switched timezones (traveling from the west coast to europe), and suddenly about half of my birthdays had shifted one day forward. i did not bother to reverse engineer the exact data stored by the contacts app, but this means that apparently, the app stores the timestamp of when you have entered a birthday, and then interprets this timestamp according to the timezone you're currently in. as a result, birthdays are stored as a combination of the date entered by the user, the time when the date has been entered, and either the timezone in effect when it was entered, or no timezone information (in the latter case, it is probably interpreted as a UTC timestamp later on).
all of this means that some of the birthdays i had entered magically shifted to one day later after making the trip (it would have looked even worse when traveling to japan, i guess; almost all birthdays would have shifted). and of course there is no user interface for looking at the time associated with a birthday, which means that it is impossible to figure out which birthdays did shift, and which ones did not. welcome to the wonderful world of iPhone simplicity and usability.
the bad thing about this bug is that it is not reversible (unless the contacts app also stores the information about which timezone you were in when you entered a birthday, which is rather unlikely). the problem is rooted in a misunderstanding of what a birthday is (it is a day or a date, depending on the model, but certainly not a timestamp) and carries this misunderstanding into the app's data model. if you really wanted to be fussy about the exact time of birth, you could extend it into a timestamp, but then you would need to capture the timezone for the place of birth as well, and this would take birthday information to a level of detail probably not interesting for the majority of users. also, very few people think of their birthday as shifting around in the calendar depending on where you were born and where you currently are; it's simply a day and it's that day depending on where you are on your birthday.
after going through the substantial user interface pain of entering about 100 birthdays, i now expect these to jump back or forth one day, depending on the timezone where i entered them, and the timezone i am in. this jumping back and forth will be unpredictable, because i cannot look at the timestamp associated with the birthday entries. for being heralded as a marvel of usability and utility, i have to say this particular detail of the way the iPhone manages contact information is not quite up to what i would expect from software being subjected to use cases (such as people traveling between timezones and expecting birthdays to be stable) and systematic testing based on those use cases.