Framework: [5.8] Date validator rules with attribute parameter trigger warnings

[LarsGrevelink]

Configuration:

• Laravel Version: 5.8
• PHP Version: 7.2.15

Description:

Using date related validation rules with an attribute name as the parameter logs a silent warning when using NewRelic. Distorting the erroneous amount of requests in NewRelic for Laravel applications using these validation rules.

Code triggering warning (line 249);
https://github.com/laravel/framework/blob/d0a33d4a398f2bd23c2689aac473a3453ece76cc/src/Illuminate/Validation/Concerns/ValidatesAttributes.php#L242-L253

Warning triggered;
E_WARNING: DateTime::__construct(): Failed to parse time string (destination_arrival_date) at position 0 (d): The timezone could not be found in the database

Affected validation rules;

• after
• after_or_equal
• before
• before_or_equal
• date_equals

Steps To Reproduce:

Any validator using a date rule and another attribute to compare its value to would trigger this warning. Example;

$validatedData = $request->validate([
    'compare_date' => 'date',
    'after_date' => 'after:compare_date',
]);

Suggested solution:

Replace the new DateTime by date_create which should be an alias for the DateTime constructor but silences these kinds of warnings. Since the code catches any thrown exceptions this seems like a valid step that could be taken.

Would love to create a PR for this change if you agree. Let me know!

[ankurk91]

Can you share sample request payload?

[driesvints]

I'll need more info and/or code to debug this further. Please post relevant code like models, jobs, commands, notifications, events, listeners, controller methods, routes, etc. You may use https://paste.laravel.io to post larger snippets or just reply with shorter code snippets. Thanks!

[LarsGrevelink]

@driesvints Unfortunately, there is not a lot to share. It's a warning which gets caught by the NewRelic PHP agent which runs on the server side. I've created a controller which reproduces this on my containers and added the error and partial trace I receive in NewRelic.

Discovered a little more while building the examples. The rules alone did not trigger the warning but when used together with date_format they do. I try to do some more testing this afternoon.

Gist; https://gist.github.com/LarsGrevelink/c3e0da3f1642b05ff7a185879a19032a

[driesvints]

Closing this issue because it's inactive, already solved, old or not relevant anymore. Feel free to reply if you're still experiencing this issue.

[LarsGrevelink]

Hi Dries,

Indeed, we patched it at our side but it’s not resolved in the framework. I didn’t receive any response on the case that I provided. I can deliver you the patch file we’re using in order to show the actual code change.

Let me know,
L

[driesvints]

@Lars can you share the code here?

[LarsGrevelink]

Hi @driesvints!

These are the contents of the patch file we use to patch the ValidatesAttributes.php in our current production environment which does no longer report the errors.

--- vendor/illuminate/validation/Concerns/ValidatesAttributes.php   2019-03-12 08:12:25.000000000 +0000
+++ vendor/illuminate/validation/Concerns/ValidatesAttributes.patch 2019-03-13 17:25:26.000000000 +0000
@@ -246,7 +246,7 @@
                 return Date::parse($value);
             }

-            return new DateTime($value);
+            return date_create($value);
         } catch (Exception $e) {
         }
     }

The samples can still be found here; https://gist.github.com/LarsGrevelink/c3e0da3f1642b05ff7a185879a19032a

[pavel-personio]

Hi @driesvints , @LarsGrevelink

We can confirm that the same issue happens to us when we are using field as a value for before_or_equal validator, together with date_format validator.

[
            'from'        =>  ['required', 'date_format:Y-m-d', 'before_or_equal:to'],
            'to'          => ['required', 'date_format:Y-m-d']
]

Regards.

[driesvints]

Atm I don't have too much time to deep dive into this so appreciating any help with figuring out if this is a bug or not.

[rossriley]

Confirmed here too.

The problem is really a PHP bug, check here: https://bugs.php.net/bug.php?id=67881&edit=1

If we have a rule that uses an attribute eg: after_or_equal:publish_date then ValidatesAttributes does this process to decide whether we are dealing with a date or an attribute.

        if (! $secondDate = $this->getDateTimeWithOptionalFormat($format, $second)) {
            $secondDate = $this->getDateTimeWithOptionalFormat($format, $this->getValue($second));
        }

What it then does is try and create a new DateTime via new DateTime('publish_date') and if that throws an exception, then it assumes we are dealing with an attribute.

The problem here is that due to the above PHP bug, when DateTime throws an exception then it also logs a warning which can't be supressed.

So patch above is a good solution since it avoids the PHP bug although it's technically not a Laravel bug.

[LarsGrevelink]

Thanks @rossriley for finding the root cause!

@driesvints with the above explanation I would like to create a PR applying the exact patch we currently use in production. It does not seem to have a notable implication on performance and we've not seen any additional errors caused by applying this fix. Good to go on your part?

[aslanahmet]

Thanks @rossriley for finding the root cause!

@driesvints with the above explanation I would like to create a PR applying the exact patch we currently use in production. It does not seem to have a notable implication on performance and we've not seen any additional errors caused by applying this fix. Good to go on your part?

Hello I have same issue.

How can I ignore this issue from newrelic? Because I can not see this warning in local development environment. I can just see this error in newrelic. @LarsGrevelink

I debugged this problem. This warning coming from ValidatesAttributes.php.
When I use validation just like this

This value is for example startDate and there is no type as startDate in Datetime class.
This is a problem but there is try catch. this function which is getDateTimeWithOptionalFormat returns empty when there is error.

This method get data from Input values according to parameter when getDateTimeWithOptionalFormat's returns value is empty. This is not best practice. @driesvints

[LarsGrevelink]

Created a pull request which fixes the issue.

@aslanahmet If you want to fix this in the meanwhile I'd suggest you use a similar way to patch the file as I talked about in an earlier comment. Ideally, I would suggest to hold on a little longer and wait for the PR to be merged.

[LarsGrevelink]

PR is merged; I'm closing the issue.

Thanks, to everyone who took the effort to look into this issue.

[driesvints]

@LarsGrevelink thanks for reporting and fixing!