"Date and time" Form API element allows entry beyond min/max values

https://www.drupal.org/files/issues/2840220-06.patch - didn't help me (D8.4.5, php7.1)
I checked Data and Data range fields.

Rerolled https://www.drupal.org/files/issues/2840220-06.patch for Drupal 8.6.x.

Now for an actual git patch. Sorry :(

I tested patch in #13, but I still experience the problem.

I have a datefield filter in views and I've pre-set the deafult value to: '1830-01-01 00:00:00'
I then apply the patch, run cron and clear cache.

Still, after, I get min="1830-01-01" inside my input element.

Just some tiny nits and a question/comment below.

1. +++ b/core/lib/Drupal/Core/Datetime/Element/Datetime.php
   @@ -242,12 +242,17 @@ public static function processDatetime(&$element, FormStateInterface $form_state
   +      $extra_attributes += array(
   

   Nit: needs short array syntax

2. +++ b/core/modules/system/tests/src/Functional/Form/DatetimeTest.php
   @@ -0,0 +1,57 @@
   +  protected $profile = 'testing';
   

   This shouldn't be necessary as it's the same as the one declared by BrowserTestBase.

3. +++ b/core/modules/system/tests/src/Functional/Form/DatetimeTest.php
   @@ -0,0 +1,57 @@
   +    $this->assertFieldByXPath('//div[@id="edit-datetime"]//input[@type="date" and @min="1900-01-01" and @max="2050-12-31"]', '', 'Found input[@type="date" and @min="1900-01-01" and @max="2050-12-31"]');
   ...
   +    $this->assertFieldByXPath('//div[@id="edit-datetime"]//input[@type="date" and @min="1900-01-01" and @max="2050-12-31"]', '2016-12-31', 'Found input[@type="date" and @min="1900-01-01" and @max="2050-12-31"]');
   ...
   +    $this->assertFieldByXPath('//div[@id="edit-datetime"]//input[@type="date" and @min="1776-01-01" and @max="2050-12-31"]', '1776-07-14', 'Found input[@type="date" and @min="1776-01-01" and @max="2050-12-31"]');
   

   It's not clear to me where these ranges are coming from, and how they are being set in FormTestDatetimeForm. Can some clarifying comments be added either to the form class or to the test itself?

4. +++ b/core/modules/system/tests/src/Functional/Form/DatetimeTest.php
   @@ -0,0 +1,57 @@
   +    // Post values w/in 1900-2050 and check min/max.
   

   Tiny nit: Can you spell out within here?

I can enter 1776-07-04 as a date in an empty element, and then this year gets used as the min year on the element instead of the range defined on the element (which is by design per a comment in DateElementBase::datetimeRangeYears()), but then you cant edit the year to be less than this ever again.

We just ran into this issue. A student accidentally entered 10/01/1850 instead of 10/01/1848 and saved the node. The student then tried to edit the node again to correct the date, but received an error stating "Value must be greater than or equal to 1850-01-01" or "Value must be 01/01/1850 or later" (see images below).

We haven't applied the patch from #17 yet, but the following work-around was successful (in case anyone reading this is unable to apply the patch yet but needs some sort of temporary solution):

• In the node edit form, hover your cursor over the erroneous value in the date field until an "x" next to the date appears.
• Click the "x" to clear the value. The value should now be something like mm/dd/yyyy instead of the incorrect date.
• Save the node.
• Edit the node again, and enter the correct value into the date field.
• Save the node again. Upon saving the node with the corrected date, you should not be receiving the error about "Value must be XYZ or later".

Believe this is a duplicate of https://www.drupal.org/project/drupal/issues/2900251 anyone willing to confirm?

Believe this is a duplicate of https://www.drupal.org/project/drupal/issues/2900251 anyone willing to confirm?

No, this is a different issue.

There is a workaround— add the Datetime Extras module. The problem is not in the data, but in the validation that the entry form imposes. The Datetime Extras module allows you to set the allowable date range for a valid entry, instead of getting the HTML 4 default 0f 1900–2050.

For #19

Addressed point 1, 2 and 4 of comments #19, still needs work for point number 3 of comment #19.

Ignoring #31 because of the deprecation errors.

Regarding #19.3 Also not understanding where the data ranges are coming from.

Also the solution here looks pretty similar to https://www.drupal.org/project/drupal/issues/2900251 which is currently marked RTBC.

So if https://www.drupal.org/project/drupal/issues/2900251 isn't addressing this issue maybe this is postponed until that is merged?

Also needs an IS update to be more clear.

Trying to fix tests of patch #31 and fixed Drupal CS issues.

Fixed failed tests of patch #33 and added test only patch this might help.

Still needs work for #32.

Updated the IS slightly about what's left todo.

Finally figured out the dates.

First set are from when the tests were created initially
Second set I think is around US. 1776 at least is. But it's before the min 1900
Third set I believe is just a random set after 2050

Tests need to be refined

Before the tests get worked on how exactly is this suppose to work?
I added a date field to a content type and min/max gets set to 1900-01-01 and 2050-12-31 with this patch. Previously it was getting no min or max.
How am I suppose to set a 1756 time? Is that covered in https://www.drupal.org/project/drupal/issues/2942828

Pulling the tests from https://www.drupal.org/project/drupal/issues/290025 to test the min/max variable at least.
Removing the old ones until

smustgrave closed #2900251: "Date and time" Form API element allows to type 6 digit year component as a duplicate. I have added it as a related issue and I am moving credit.

This could use an issue title update. What 'buggy' behavior is being fixed here?

@quietone what about "Datetime missing min/max attributes"
This issue fixes a problem where min and max attributes were not be added to the date field.

In addition, I can enter 1776-07-04 as a date in an empty element

The original issue talks about this but I don't know how they set that up with this patch.

Any suggestion on how best to proceed?

This issue is already resolve in the latest version , Adding screenshot.

Thankyou

#37 Patch Applied on 10.1.x-dev and it fixes the issue.

This could use an issue title update. What 'buggy' behavior is being fixed here?

I've updated the title to capture the bugginess: "Date and time" Form API element allows entry beyond min/max values

This issue is being reviewed by the kind folks in Slack, #need-reveiw-queue. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

Looking at the proposed resolution in the issue summary, it seems that the patch only implements the "Add the min/max elements even when the value on the element is empty." part. All the rest is missing, which is a lot. So this is very far from ready, unfortunately.

If this change breaks the functionality of the date field for working with dates outside the default range, then I think we also can't just rescope this issue and do the rest in a follow-up. We must at least ensure that people who use the field with existing data outside of the default range can still use the date field until the follow-up is implemented.

The issue linked from the top of the issue summary mentions that it is annoying for editors when they accidentally enter a 6 digit year instead of entering a 4 digit year and then the first 2 digits of the next date component. I tested the patch in both current Firefox and Chromium on Linux and although min and max are now set to the default date range, I can still enter 6 digit years. Only when I then try to submit the form, instead of getting an error from Form API about the required date format, I now get a browser validation error (which will also enforce that the date is within the date range specified). I'm not sure how to fix this, maybe this would need some Javascript?

I would also suggest to use an ordered list instead of an unordered list for the proposed resolution in the issue summary, as that will make it easier to refer to individual items in comments.

https://www.drupal.org/project/datetime_more
The "Datetime More Widget" module allows the user to independently specify the minimum and maximum year 0001-9999.