There's a bit of a problem with this, take the following:

It's a contrived example, but assume people want to merge these 3 artists together, all into Artist A. What should the begin date be? 2010-02? 2010-05? 2011-05-20? 2011-02-20?

Decision required: how should we handle this merge?

I wouldn't do it too complicated (because every merge strategy might be counter-intuitive to some). My proposal is:

• if the target has no column (day/month/year) filled in at all, take the one of the merged entity
• in all other cases, do not merge at all

The reason is, in 99.99% of the cases I've seen, we always merge a wrong (bogus/duplicated) artist into the correct one. Since it is wrong, I wouldn't trust the date at all.

A merge is still multiple old-entities. In the above example, merge A&B into C. What should the year be? The problem is that when we consider the date as an atomic value, there is a conflict. (This is true for other data, such as merging the artist type).

What if we checked for this case and alerted the user that there is a conflict? We could prevent the merge until the birthdays have been fixed up. How does that sound?

Hmm, I don't think that's a good idea... that means normal users will have to wait 4 weeks to merge artists where one has a bogus date. I think the best option still is to only update the birthday of the merged-into artist ("C" in the example), if it is completely empty. If so, the most "complete' (or a random if both have the same completeness) one of "A" and "B" should be used.

For example, I have a bogus artist with year "2000-01-01" (because that was the day he started performing, people sometimes confuse this), and I merge it into the correct artist with birth date "1982" (nothing more known), I certainly not want "01-01" appended to the year.

Merged artists are almost always mistakes created by some careless editors, the information shouldn't be rated to high.

A decision has not been reached here yet, I agree more with hrglgrmpf here - blocking merging is not a way to go.

I agree with hhgfhgmrmghfpf. Lets go with:

• if the target has no column (day/month/year) filled in at all, take the one of the merged entity
• in all other cases, do not merge at all

I'll add the one step that if no merge happens, ModBot should leave a note on the edit that states all of the old dates that could've been merged and tell that no date has been merged. This allows the editor to go in an manually set a date from the data preserved in the edit note.

I believe there's a sensible merge strategy now. This in review at http://codereview.musicbrainz.org/r/1550/ and available for testing at http://test.musicbrainz.org