Remove hard-coded #date_year_range making it impossible to enter dates < 1900, > 2050. Instead make them optional and configurable in the UI

Not sure if this falls under the "do-it-all" use case we are trying to avoid in core, but this would be a great addition for DateTime Extras.

Age compliance can be implemented in contrib and or in custom code in numerous ways right now. The datetime and daterange elements both have `#date_year_range` attributes that can be added (via alters) where needed (though I think that just sets min/max attributes on the elements. And, adding your own validation functions can also be done with alters.

I am not saying this isn't a useful feature, but I do not see where this becomes a mandatory for Drupal core to implement this feature on all datetime, daterange, and timestamp fields regardless of how they are being used.

Is there any temporary solution for this, eg on JS or client side?

You can use this contrib module with the provided patch to configure the year reange

@michiellucas - I'm guessing you meant to link to DateTime Extras?

@akmalfikri - try something like this in a custom module inside a HOOK_form_alter method (match the method to the correct form(s):

$form['field_dob']['widget'][0]['value']['#date_year_range'] = '1930:-13';

A slightly annoying thing about `#date_year_range`: while it can do relative dates (as above), you apparently can't reverse the year order by swapping the numbers around? (anecdotally quite a common request, e.g. Date of Birth fields).

I found some code that does this by hooking into template_preprocess_select and grabbing, reversing the array.

Yeah, reverse would definitely be very helpful, just landed here as well when searching for an existing issue about that.

+1 on exposing the year range setting in the widget that seems simple enough, don't want to add another contrib module just for that so I'm currently using custom code for that.

What is the status of getting this into core, please?

Thanks @wturrell for your hint to @akmalfikri, it has proven to be useful to me as well.
On top of that, I used #3269890: #date_year_range is not validated server-side to enforce the year range on server-side validation (instead of only client-side, via HTML 5).

I totally agree with @berdir in #12.
It's a not a good decision and assumption for a popular (not only developer) CMS like Drupal to set a hard-coded date limit in code, which non-developers can not change easily. Having dates outside of that area is absolutely possible!

See https://git.drupalcode.org/search?search=%23date_year_range&nav_source=n...

Some examples:
- Using Drupal for genealogy or other historical dates (< 1900)
- Using Drupal for birthdates (>= today doesn't make sense)

I updated the issue summary and changed this to a Bug report because of the reasons given above.

I see two possible solutions here:

1. Remove the hard-coded limit and make this a feature-request again
2. Add a UI to set the limit and set the current limits as defaults if needed for BC

I'd vote for (2) because I think (1) would at least resolve the bug but wouldn't solve the need for a better UX solution at the same time.

Please note the various related issues around.

I adjusted the issue summary accordingly and added the template.

Setting year zero (0) as minimum for the workaround I ran into this: #3585723: #date_year_range does not support years < 1000
Also I think we should allow setting no value for one of both values: #3556851: Deprecated function: preg_match(): Passing null to parameter #2 ($subject)