When using the date validators (before, after, after_or_equal, before_or_equal) both with and without date_formats the validator will fail when the length of the key is equal to 1.
Cause
Without date_format rule it is caused by getDateTimestamp inside Illuminate\Validation\Concerns\ValidatesAttributes
When given bar this method outputs null (as Date::parse exception is silenced). When given b the method outputs a Date Carbon object containing the current date + a timezone offset based on the letter given where a = 1 and b = 2 etc..
Similarly when the date_format validation rule is provided another method checkDateTimeOrder inside the same class is called which also performs a similar check
Since current date time object is returned instead of null both will check the rules against now rather then the referenced attributed.
Possible fix
As possible fix we could check if the referenced attribute exists if it does use it if it doesn't assume the value provided is a a strtotime compatible value.
However when testing this out one test breaks (see referenced PR) where if the field being referenced is a valid also a date input
Laravel Version
11.22.0
PHP Version
8.3.7
Database Driver & Version
No response
Description
When using the date validators (before, after, after_or_equal, before_or_equal) both with and without date_formats the validator will fail when the length of the key is equal to 1.
Cause
Without
date_format
rule it is caused bygetDateTimestamp
insideIlluminate\Validation\Concerns\ValidatesAttributes
When looking closer at this methods implementation it contains a reference to
getDateTime
When given
bar
this method outputs null (asDate::parse
exception is silenced). When givenb
the method outputs aDate
Carbon object containing the current date + a timezone offset based on the letter given wherea
= 1 andb
= 2 etc..Similarly when the
date_format
validation rule is provided another methodcheckDateTimeOrder
inside the same class is called which also performs a similar checkSince current date time object is returned instead of
null
both will check the rules against now rather then the referenced attributed.Possible fix
As possible fix we could check if the referenced attribute exists if it does use it if it doesn't assume the value provided is a a
strtotime
compatible value.However when testing this out one test breaks (see referenced PR) where if the field being referenced is a valid also a date input
Steps To Reproduce
The same happens with the following