I had an issue which was only possible to solve by manually changing the value in phpmyadmin. It was like this:

The date of birth field is set to show only certain years. A user can register and enter his date of birth. But as time passes his birthday year slips out of the valid range of years.
For example: If set in user manager only show -20 to -25 years, this means that actually only years from 1991 to 1986 will be shown.
Before new year, the shown age range was 1990 - 1985.

If last year a user has registered with year of birth 1985, today his date of birth is no longer valid and this causes trouble.
First of all the year does no longer show up in the backend in user edits. Only day and month are still visible, the drop down field for year remains empty. This is bad, as even admin now can no longer tell what was the original year the user has registered with.
But even if admin wants to edit user details (maybe change of email or other stuff), it is no longer possible to save this this user, as there is always the validation popup, tellig that the age range of this user is out of bounds and preventing to save the user.
So there is no way to edit this legit user when his initial age range slips out of the actual age range.
And this does not make sense. The only solutions would be:
- To enter a new date of birth, but this would have a wrong year then, so it does not make sense.
- To exceed the age range, but this does not make sense either as there is no intention to exceed the age range for new users, but old user of course get older every year and this should be accounted for.

So I think this is something that should be taken care of. To prevent users, that are already registered to fall under the restriction of the validation when editing fields.

Actually I do see an issue here for three reasons:

1. The setting as is is breaking funcionality as simple edits of user data is not possible anymore without changing the value. So if users do not have permission to change this value (and date of births are not meant to be changed) can no longer change ANY value of this user data. So one setting destrys the entire usability of the edit functions.

2. It is breaking functionality as the year value doesn´t even get displayed anymore. So this information simply vanishes and is no longer available.

3. Changing the setting to static is not a solution if you target a specific age group as this setting will apply to new members as well as to registered members.

I believe this date field is considered to be used for age relevant purposes. Using it for date of birth entries it is something that remains static as it is as there is no need for users to play around with it. So there is no need to give them control over it nor to change the value on a yearly basis.
So it is hard to believe that the solution would be to let them change their birthday only to be able to edit other user data or to set settings to static and target a completely different age group than intended.

The real solution would be to check upon edit if the field setting allow user edits. If it does not allow user edit, validation should turn itself off for this field and simply not touch the field. It cannot be changed anyway, why touch it?

Hmm. I wonder how this can be intentional: Without changing a thing from one day to the other users can no longer edit their data. And how can hiding the field be an option if I want it to be visible.

Again: I think it is a bit weak to call this not a bug or even intentional, if it is not possible for a user or even admin to edit users anymore without changing anything. Just as time is passing by it transforms itself from a working community into a non working community. How can this be intentional?

I am just asking for a failuresafe operation. And I cannot see that this is the case the way it is now. And even if I would choose to change the min years, they are not even visible in the backend. So it is impossible to tell how much it must be increased.
So again: I don´t think it is a customization issue, I think the way it is working now it is not failuresafe, In fact it has the potential to break functionality without that anybody has changed anything.

For 2.0 it would be good if you reconsider the ways this is working now. I believe the current approache is a bit too simple for a field of such a variety and importance.