Unknown setter 'date' when using Carbon

[indesignlatam]

Im running an existing Laravel website and testing it on hhvm which i found increases performance in about 300% or 400% sometimes even more.

When using briannesbitt/Carbon in some point i get the following error:

Running hhvm version
HipHop VM 3.8.1 (rel)
Compiler: tags/HHVM-3.8.1-0-g3006bc45691762b5409fc3a510a43093968e9660
Repo schema: 253b3802ce1bcd19e378634342fc9c245ac76c33
Carbon version 1.2.0
Laravel 5.0

InvalidArgumentException in Carbon.php line 583:
Unknown setter 'date

in Carbon.php line 583
at Carbon->__set('date', '2015-08-09 14:57:22.000000')
at DateTime->__sleep()
at serialize(array(object(Carbon), '1')) in Builder.php line 174
at Builder->generateCacheKey() in Builder.php line 162
at Builder->getCacheKey() in Builder.php line 152
at Builder->getCacheInfo() in Builder.php line 66
at Builder->getCached(array('*')) in Builder.php line 45
at Builder->get() in Builder.php line 1432
at Builder->getCountForPagination() in Builder.php line 248
at Builder->paginate('20') in ListingFEController.php line 189
at ListingFEController->index(object(Request))
at call_user_func_array(array(object(ListingFEController), 'index'), array(object(Request))) in Controller.php line 246
at Controller->callAction('index', array(object(Request))) in ControllerDispatcher.php line 162
at ControllerDispatcher->call(object(ListingFEController), object(Route), 'index') in ControllerDispatcher.php line 107
at Closure$Illuminate\Routing\ControllerDispatcher::callWithinStack(object(Request))
at call_user_func(object(ControllerDispatcher::callWithinStack;725649350), object(Request)) in Pipeline.php line 141
at Closure$Illuminate\Pipeline\Pipeline::getInitialSlice(object(Request))
at call_user_func(object(Pipeline::getInitialSlice;450427292), object(Request)) in Pipeline.php line 101
at Pipeline->then(object(ControllerDispatcher::callWithinStack;725649350)) in ControllerDispatcher.php line 108
at ControllerDispatcher->callWithinStack(object(ListingFEController), object(Route), object(Request), 'index') in ControllerDispatcher.php line 67
at ControllerDispatcher->dispatch(object(Route), object(Request), 'App\Http\Controllers\ListingFEController', 'index') in Route.php line 204
at Route->runWithCustomDispatcher(object(Request)) in Route.php line 134
at Route->run(object(Request)) in Router.php line 702
at Closure$Illuminate\Routing\Router::runRouteWithinStack(object(Request))
at call_user_func(object(Router::runRouteWithinStack;233203341), object(Request)) in Pipeline.php line 141
at Closure$Illuminate\Pipeline\Pipeline::getInitialSlice(object(Request))
at call_user_func(object(Pipeline::getInitialSlice;450427292), object(Request)) in Pipeline.php line 101
at Pipeline->then(object(Router::runRouteWithinStack;233203341)) in Router.php line 703
at Router->runRouteWithinStack(object(Route), object(Request)) in Router.php line 670
at Router->dispatchToRoute(object(Request)) in Router.php line 628
at Router->dispatch(object(Request)) in Kernel.php line 214
at Closure$Illuminate\Foundation\Http\Kernel::dispatchToRouter(object(Request))
at call_user_func(object(Kernel::dispatchToRouter;1797950995), object(Request)) in Pipeline.php line 141
at Closure$Illuminate\Pipeline\Pipeline::getInitialSlice(object(Request)) in VerifyCsrfToken.php line 43
at VerifyCsrfToken->handle(object(Request), object(Pipeline::getInitialSlice;450427292)) in VerifyCsrfToken.php line 17
at VerifyCsrfToken->handle(object(Request), object(Pipeline::getInitialSlice;450427292)) in Pipeline.php line 125
at Closure$Illuminate\Pipeline\Pipeline::getSlice(object(Request)) in ShareErrorsFromSession.php line 55
at ShareErrorsFromSession->handle(object(Request), object(Pipeline::getSlice;450427292)) in Pipeline.php line 125
at Closure$Illuminate\Pipeline\Pipeline::getSlice(object(Request)) in StartSession.php line 61
at StartSession->handle(object(Request), object(Pipeline::getSlice;450427292)) in Pipeline.php line 125
at Closure$Illuminate\Pipeline\Pipeline::getSlice(object(Request)) in AddQueuedCookiesToResponse.php line 36
at AddQueuedCookiesToResponse->handle(object(Request), object(Pipeline::getSlice;450427292)) in Pipeline.php line 125
at Closure$Illuminate\Pipeline\Pipeline::getSlice(object(Request)) in EncryptCookies.php line 40
at EncryptCookies->handle(object(Request), object(Pipeline::getSlice;450427292)) in Pipeline.php line 125
at Closure$Illuminate\Pipeline\Pipeline::getSlice(object(Request)) in CheckForMaintenanceMode.php line 42
at CheckForMaintenanceMode->handle(object(Request), object(Pipeline::getSlice;450427292)) in Pipeline.php line 125
at Closure$Illuminate\Pipeline\Pipeline::getSlice(object(Request))
at call_user_func(object(Pipeline::getSlice;450427292), object(Request)) in Pipeline.php line 101
at Pipeline->then(object(Kernel::dispatchToRouter;1797950995)) in Kernel.php line 115
at Kernel->sendRequestThroughRouter(object(Request)) in Kernel.php line 84
at Kernel->handle(object(Request)) in index.php line 53

[jwatzman]

It looks like the Carbon library actually doesn't support 'date': https://github.com/briannesbitt/Carbon/blob/c734a138a3a14314f516e08dc9951c33e37fa090/src/Carbon/Carbon.php#L546-L585

Do you have a more isolated example of different behavior between HHVM and PHP? Otherwise, it's not even clear this is an HHVM bug, as opposed to your code passing something into Carbon which it doesn't understand.

[indesignlatam]

Im not very sure how to isolated it. I can use any guidance to do it.

• The problem only appears when using HHVM the same application running in PHP wont crash.
• It seems that the problem is when caching the Carbon element, if i remove the caching it wont crash.

Query builder instance under PHP

Builder {#531 ▼
  #query: Builder {#530 ▼
    #cacheKey: null
    #cacheMinutes: "1"
    #cacheTags: null
    #cacheDriver: null
    #connection: MySqlConnection {#183 ▶}
    #grammar: MySqlGrammar {#185 ▶}
    #processor: MySqlProcessor {#186}
    #bindings: array:6 [▼
      "select" => []
      "join" => []
      "where" => array:2 [▼
        0 => Carbon {#537 ▼
          +"date": "2015-08-10 21:01:36.000000"
          +"timezone_type": 3
          +"timezone": "America/Bogota"
        }
        1 => 1
      ]
      "having" => []
      "order" => []
      "union" => []
    ]
    +aggregate: null
    +columns: null
    +distinct: false
    +from: "listings"
    +joins: null
    +wheres: array:3 [▶]
    +groups: null
    +havings: null
    +orders: array:2 [▶]
    +limit: null
    +offset: null
    +unions: null
    +unionLimit: null
    +unionOffset: null
    +unionOrders: null
    +lock: null
    #backups: []
    #bindingBackups: []
    #operators: array:26 [▶]
    #useWritePdo: false
  }
  #model: Listing {#526 ▶}
  #eagerLoad: array:2 [▶]
  #macros: array:4 [▶]
  #onDelete: Closure {#536 ▶}
  #passthru: array:10 [▶]
}

This might be the serialized object, so this will cache successfully in php but not in HHVM

[damiencriado]

Same error :/ Any news ?

[2015-09-18 23:00:32] testing.ERROR: exception 'InvalidArgumentException' with message 'Unknown setter 'date'' in Carbon.php:583
Stack trace:
#0 (): Carbon\Carbon->__set()
#1 (): DateTime->__sleep()

[indesignlatam]

In my case it was caused only when caching the Carbon object, so when i need the object to be cached i dont use Carbon.

Its not a the way it must be, but it works.

[earnaway]

Is there any chance of this getting fixed, as our code which is fine on PHP is breaking on HHVM because of "Unknown setter 'date'" too.

[jwatzman]

@earnaway almost 0 chance without an isolated test case, i.e., one that doesn't depend on Carbon but exhibits the same root difference that causes the problem here. The only information we have so far is "something causes Carbon caching to fail under HHVM". The OSS team is super strapped for people right now (enough that I'm not even on the team any more and am just trying to pitch in when I can) -- this needs some legwork in figuring out where exactly the difference is between HHVM and PHP.

With such a test case... chances are still low, depending on the issue to be honest, but they aren't 0. And often times community members like fixing weird differences, depending on what the root issue ends up being, and the chances of a good PR being merged which fixes this are very high.

[Bazman]

I'm no expert on the source code, but the issue seems to be in the way HHVM serialises the DateTime object.

During serialisation, the DateTime __sleep method is called. It sets the "date" field in the object. This in turn seems to call the __set method on the Carbon object (which inherits from DateTime) but "date" isn't a valid option for Carbon's __set method, and so the exception is thrown.

hhvm/hphp/runtime/ext/datetime/ext_datetime.cpp

Line 259 in df46f65

this_->o_set(s_date, data->format(s_ISOformat));

I don't really follow how PHP serialises its DateTime implementation, but the implementations between PHP and HHVM seem very different.

It does seem odd that such a low level method in HHVM is causing magic functions being executed at the PHP level. Not really sure if thats normal or not.

[farizluqman]

Weird and hacky solution to this:

This is what I've added at the src/Carbon/Carbon.php under the method __set.

/**
     * Set a part of the Carbon object
     *
     * @param string $name
     * @param string|int|\DateTimeZone $value
     *
     * @return string
     * @throws \InvalidArgumentException
     */
    public function __set($name, $value)
    {
        if(defined('HHVM_VERSION')){
            return '';
        }
        switch ($name) {
            // ...
        }
    }

Not sure if it affect other things, but it is my workaround for now.

[alex94040]

More on this issue: https://laravel.io/forum/03-31-2015-cachecarbon-problem-under-hhvm

[lexidor]

I am going over old issues on this repository, to see which ones apply to the current versions of hhvm.

This issue applies to running php code on hhvm. Hhvm nolonger supports running php code since hhvm version 4.0.0.

Hhvm has also removed the magic method __set() in hhvm 4.56.0.