for testing and deploying your application
for finding and fixing issues
for empowering human code reviews
<?php
declare(strict_types=1);
namespace Rinvex\Support\Traits;
use DateTimeZone;
use Illuminate\Support\Arr;
trait HasTimezones
{
/**
* Return a timestamp as DateTime object.
*
* @param mixed $value
* @return \Illuminate\Support\Carbon
*/
protected function asDateTime($value)
$datetime = parent::asDateTime($value);
$setAttributeCalled = Arr::first(debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 30), function ($trace) {
debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 30)
array
object<Illuminate\Support\iterable>
It seems like the type of the argument is not accepted by the function/method which you are calling.
In some cases, in particular if PHP’s automatic type-juggling kicks in this might be fine. In other cases, however this might be a bug.
We suggest to add an explicit type cast like in the following example:
function acceptsInteger($int) { } $x = '123'; // string "123" // Instead of acceptsInteger($x); // we recommend to use acceptsInteger((integer) $x);
return $trace['function'] === 'setAttribute';
});
// When setting attributes, skip custom timezone setting,
// and use default application settings for consistent storage!
if (! $setAttributeCalled && app()->bound('request.user') && $timezone = optional(app('request.user'))->timezone) {
$datetime->setTimezone(new DateTimeZone($timezone));
}
return $datetime;
rinvex /
laravel-support
It seems like the type of the argument is not accepted by the function/method which you are calling.
In some cases, in particular if PHP’s automatic type-juggling kicks in this might be fine. In other cases, however this might be a bug.
We suggest to add an explicit type cast like in the following example: