Carbon: Best way to transform \DateTime in \Carbon

[Unibozu]

Hi there,

This is not a proper issue, but more a question : is there a proper way to transform a \DateTime object (often returned by third party library - like Doctrine in my case) to a Carbon powered object ?
As the constructor accepts the same arguments as \DateTime it is possible to format the \DateTime to a unambiguous string and send it to Carbon but it doesn't feel nice.

Keep up the good work

[briannesbitt]

Right from the docs....

Finally, if you find yourself inheriting a \DateTime instance from another library, fear not! You can create a Carbon instance via a friendly instance() function.

$dt = new \DateTime('first day of January 2008');   // <== instance from another API
$carbon = Carbon::instance($dt);
echo get_class($carbon);                               // 'Carbon\Carbon'
echo $carbon->toDateTimeString();                      // 2008-01-01 00:00:00

Definitely makes me think we are in need of a separate website with better navigation !

[dinamic]

It's unfortunate that Carbon::instance() does not make use of \DateTimeInterface. My use case involves using \DateTimeImmutable, which is not well supported atm.

My workaround:

new Carbon($dateTime->format('Y-m-d H:i:s.u'), $dateTime->getTimezone())

[kylekatarnls]

As you can see: Carbon::instance(new DateTimeImmutable()) is not a problem. It's supported since Carbon 1.26.

http://try-carbon.herokuapp.com/?embed&theme=xcode&border=silver&options-color=rgba(120,120,120,0.5)&input=%24date%20%3D%20new%20DateTimeImmutable()%3B%0A%0Aecho%20Carbon%3A%3Ainstance(%24date)%3B%0A

Carbon::instance() takes DateTimeInterface as parameter. You can create Carbon/CarbonImmutable from both DateTime/DateTimeImmutable using instance method. And as DateTimeInterface cannot be implemented by the user (PHP restriction) it can only be DateTime/DateTimeImmutable or a class that extend one or the other.

If you still have trouble please fill a complete issue following the template so we'll have all informations we need to help you.

[dinamic]

@kylekatarnls thanks for explaining. Turned out we are running 1.22. We'll get to revise on what's stopping us from migrating to a newer version.

[kylekatarnls]

New features require minor update in semantic version, that's why you should have ^1.x or ^2.x and should run composer update from time to time (for example when your own library/product has a minor release). Also, Carbon 1 was mostly still supported because of Laravel requirement, as Laravel stopped to support its version 5.7 (the last one that used Carbon 1), we'll progressively stop the maintenance of the version 1. The last minor release of Carbon 1 should come before the end of 2019, so prefer to upgrade directly to ^2, it's not a big step, it's 99% backward compatible, breaking changes are listed here: https://carbon.nesbot.com/docs/#api-carbon-2