Form checking: Craft allows to enter invalid dates

[JuliaSang]

Describe the issue
Raising on behalf of @vivienlacourba from W3C

When editing a content entry it is possible to enter an invalid date, Craft will accept saving the entry without reporting that the entered data is invalid.

To reproduce

On any content entry that accept a date (e.g. Alumni).

Test 1:

• In a date field enter "31/31/2021"
• Click Save
• Craft will store a different date "7/31/2023"

Test 2:

• In a date field enter "abcd"
• Click Save
• Craft will store a null value (the resulting date input field will be empty)

Expected behavior

In both cases the form submission should fail indicating that "31/31/2021" (or "abcd") is not a valid dates.

[brandonkelly]

Thanks for the report!

• In a date field enter "31/31/2021"
• Click Save
• Craft will store a different date "7/31/2023"

This is awkward but actually working as expected. Assuming your user account’s formatting locale is set to “English (United Kingdom)”, Craft knows the submitted date will be in the format d/m/Y e. And if you were to run the following PHP code:

DateTime::createFromFormat('!d/m/Y e', '31/31/2021 UTC')

That would return a DateTime object with a value of 2023-07-31 00:00:00.000000. The way it sees it, the 13th month of 2021 is January 2022; the 14th month of 2021 is February 2022; etc… and the 31st month of 2021 is July 2023. Does that make sense?

* In a date field enter "abcd"
* Click Save
* Craft will store a null value (the resulting date input field will be empty)

Yeah that’s a legitimate bug. Unfortunately the way we handle user-submitted date values, we can’t tell the difference between an invalid date and an empty date, so all invalid values are just considered empty.

Good news is, we’ll have both of these fixed in Craft 4, as we are moving all date/time inputs to the native browser date and time types. So it won’t be possible to submit these invalid values in the first place. We’ve already made that change for mobile browsers in fact (see #9903).