[5.3] Revert #16692 and make date_format work with ISO8601 again

[mfn]

Fixes #16842

This PR:

• Reverts [5.3] Fix date_format validation for all formats #16692 because of [5.3] validateDateFormat breaks on dates with timezones #16842
• Adds tests for ISO 8601 dates (the problem of [5.3] validateDateFormat breaks on dates with timezones #16842 )
• Adds a test for the problem [5.3] Fix date_format validation for all formats #16692 tried to fix (so it can be flipped once we've a proper fix not breaking the other stuff)

I hope you appreciate this effort for the ongoing quality of the framework.

[themsaid]

@rohitsubedi, @samundra, @ankitpokhrel, @gkunwar

Can you please help us with this issue? Is there a better way to validate date formats with support for the Zulu Time Zone Identifier?

[themsaid]

According to http://php.net/manual/en/function.date.php

P Difference to Greenwich time (GMT) with colon between hours and minutes

T Timezone abbreviation

Your tests pass if you use T instead of P. It used to pass before because date format validation was failing in multiple situations not because it was correct.

[mfn]

Your tests pass if you use T instead of P

Please understand that before #16692 , all of the following formats where accepted for either T and P:

$ ./artisan tinker
Psy Shell v0.7.2 (PHP 7.0.14-1+deb.sury.org~trusty+1 — cli) by Justin Hileman
>>> \Illuminate\Foundation\Application::VERSION
=> "5.2.45"
>>> $rule = 'date_format:Y-m-d\TH:i:sP';
=> "date_format:Y-m-d\TH:i:sP"
>>> Validator::make(['a' => '1991-07-03T12:00:00Z', 'b' => '1991-07-03T12:00:00EST', 'c' => '1991-07-03T12:00:00+02', 'd' => '1991-07-03T12:00:00+02:30'], ['a' => $rule, 'b' => $rule, 'c' => $rule, 'd' => $rule])->errors()->all();
=> []
>>> $rule = 'date_format:Y-m-d\TH:i:sT';
=> "date_format:Y-m-d\TH:i:sT"
>>> Validator::make(['a' => '1991-07-03T12:00:00Z', 'b' => '1991-07-03T12:00:00EST', 'c' => '1991-07-03T12:00:00+02', 'd' => '1991-07-03T12:00:00+02:30'], ['a' => $rule, 'b' => $rule, 'c' => $rule, 'd' => $rule])->errors()->all();
=> []

And now, after #16692 :

$ ./artisan tinker
Psy Shell v0.8.0 (PHP 7.0.14-1+deb.sury.org~trusty+1 — cli) by Justin Hileman
>>> \Illuminate\Foundation\Application::VERSION                                                                                                                                        => "5.3.28"
>>> $rule = 'date_format:Y-m-d\TH:i:sP';
=> "date_format:Y-m-d\TH:i:sP"
>>> Validator::make(['a' => '1991-07-03T12:00:00Z', 'b' => '1991-07-03T12:00:00EST', 'c' => '1991-07-03T12:00:00+02', 'd' => '1991-07-03T12:00:00+02:30'], ['a' => $rule, 'b' => $rule, 'c' => $rule, 'd' => $rule])->errors()->all();
=> [
     "The a does not match the format Y-m-d\TH:i:sP.",
     "The b does not match the format Y-m-d\TH:i:sP.",
     "The c does not match the format Y-m-d\TH:i:sP.",
   ]
>>> $rule = 'date_format:Y-m-d\TH:i:sT';=> "date_format:Y-m-d\TH:i:sT"
>>> Validator::make(['a' => '1991-07-03T12:00:00Z', 'b' => '1991-07-03T12:00:00EST', 'c' => '1991-07-03T12:00:00+02', 'd' => '1991-07-03T12:00:00+02:30'], ['a' => $rule, 'b' => $rule, 'c' => $rule, 'd' => $rule])->errors()->all();
=> [
     "The c does not match the format Y-m-d\TH:i:sT.",
     "The d does not match the format Y-m-d\TH:i:sT.",
   ]

I think what the author if #16692 is after is a more strict validation of dates. This requirement is entirely reasonable. But it is not the only truth by what developers may need from the validation. Especially not one which worked that way for quite some time (years?).

I urge the PR author to re-think about changing the existing date_format and come up with a solution which will not break existing code.

Some suggestion could be:

• introduce date_format_strict or
• a flag to date_format
• etc.

But an important thing like a validation rule should not break existing code; especially not in such a minor patch release. Yes, I know Laravel sadly doesn't follow semantic versioning, but that doens't mean it's ok to break code out there at will IMHO.

[taylorotwell]

Reverting this since we can't have any breaks on a patch release.

[xxRockOnxx]

Is there a fix for this that I missed or is it really reverted? Because I am experiencing this on 5.4.33

Tried copying the same snippet @mfn posted on my console and got the same error.

[mfn]

Is there a fix for this that I missed or is it really reverted? Because I am experiencing this on 5.4.33

It was re-re-verted, as in: it got rolled back in 5.3 (this PR) and was re-introduced in 5.4.

From my POV this change per se is bad strategy, but views on this matter differ.

My "fix": I simply forego Laravels date_format validation and rolled my own custom_date_format roughly looking like this (i.e. it's the pre 5.3 and the code form this PR):

    public function validateCustomDateFormat(string $attribute, $value, array $parameters): bool
    {
        $this->requireParameterCount(1, $parameters, 'custom_date_format');

        if (!is_string($value)) {
            return false;
        }

        $parsed = date_parse_from_format($parameters[0], $value);

        return $parsed['error_count'] === 0 && $parsed['warning_count'] === 0;
    }