Issue with date validation

Maybe i am really the only one who see the shortcomings of this field in regards of a real date validation to make this field usable for a real age validation. There is this other thread I started, which details other problems with this field when it comes to a exact date validation which takes not only into account the year but also month and date.
My simple suggestion to stop the site from being unusable would be simply to stop validating a field a user cannot change. This is what causes the trouble and this is what does not make sense. It is like an infinte loop. The field is set to required for registration. And it is set to not to be changable by the user. So why trying to validate it. It has been validated for registration and it was good. The user cannot change it at any later point, so why validating it when the user wants to edit something completely different? This is what causes the trouble and this is what does not make sense. If there is a chance for the user to enter some wrong input upon edit I would be happy to have this validation in place. But for a field that a user is not allowed to change it simply does not make any sense.
It would be a simple additional parameter in the field setting asking if validation should be turned off for editing. My fear is that this behaviour cannot be changed by a plugin.

That was the user side. For the admin side I think it is worse as of course admin should be able to overwrite almost everything in the backend. I mean there is this setting in the backend saying something like "Turn off all validation for backend editing" but still, for this field even backend editing is not possible.

Best way of course would be to have a real age/dob date validation field which was specifically designed for date valiadataion, not only for year validation.

Best way of course would be to have a real age/dob date validation field which was specifically designed for date valiadataion, not only for year validation.

Exactly, this is why I recommend you develop a new feildtype to meet your needs. As stated before the date field is very very generic; it is intentionally designed as such.

I do not agree that validation should simply halt because a field is read only. Again, it's a generic field and you should develop a new fieldtype plugin if you need something much more specific. We'll be reviewing re-design of many fieldtypes with release of CB 2.0, but changes you're suggesting is too great this late in release.

Your site will not stop working just because 1 silly field can't be updated; this is certainly not the case and being blown quite out of proportion. I suppose could be the case if your entire site is highly dependent on that single field, which again you should develop your own fieldtype so it behaves EXACTLY as you need it to.

Thanks for your update. But I don´t think it is that easy:
For a site that requires user to update their profile pages frequently this is a serious issue. I wonder if I have made myself clear enough that no profile edit at all is possible as the field is set to read only. So it is not like just to skip that field when a user wants to edit his profile. The user cannot edit any field anymore as the data does not get saved.
See there are a lot of other fields in Community Builder. There is a field for a username and a password and email and so on and so on. And for each field the field manager allows to specify a rulset for registration and one for user edits. So it seems that the developers when they have created these fields in fact did understand that registration and user edit may require different sets of rules.
For a reason nobody understands, they decided to leave that path for the date field. So basically all I am saying is that a user edit requires a different handling, other validation rules or validation even competely turned off and should not be validated against the same ruleset that is used for registration.
I hope you will not gonna deny that registration and user edit are 2 different situtations.
So if you don´t wanna take it as a bug, take it as a suggestion to add a second set of validation to cover the user edits. Then and only then your suggestion makes sense and you could set a fixed minumum year which would cover a regular humans life span. For registration then it would be possible to have a dynamic set and for edits it would be possible to have a static set.
But the way it is I believe this field falls back behind the standards of all other fields which allow different validation for registration and user edits.
I might be doing a recoding, but coding a completely new plugin with all the deep integration into the core same as the existing field only for a simple statement, this seems completely out of proportion to me.