Another thing which I don’t understand: Why even use X-APPLE-OMIT-YEAR if 1604 is assumed in any case? Why not just write partial dates as BDAY:1604-mm-dd (and assume that every date with 1604 is a partial date), wouldn’t it be the same?
Or does Apple use X-APPLE-OMIT-YEAR=1605 (or another non-1604-year) if the BDAY year is really 1604?
That is indeed a good question. I’ll try to do some tests when I get the next chance to test with an iPhone (I don’t have one myself).
Why can’t the server be improved so that it understands vCard 4?
Simply because the server is not under my control. I agree that upgrading the server really is the only way to add new features though.
Restrict Android to not offer partial dates in the contact schema at all, so that users cannot enter partial dates. This is how it has been until users have explicitly requested this feature because it’s available in Android and it’s available in vCard 4. Unfortunately, it’s not possible to (dis)allow partial dates according to server vCard 4 support because this support may change from sync to sync (and even if it wouldn’t, it can’t be set per account in Android).
I wasn’t aware of that.
So, there’s always a case with inconsistent behavior, which is a logical consequence of the fact that vCard 3 doesn’t support partial dates.
Now: Which case is more important?
To be honest, the arguments for both sides are pretty good and I’m no longer sure which one really is the best choice. (Maybe unless the answer to "
Or does Apple use X-APPLE-OMIT-YEAR=1605 (or another non-1604-year) if the BDAY year is really 1604?" is yes, since option 3 would probably cause the least loss in that case.)