[Proposal] Switch from Carbon to Chronos

[it-can]

It seems that the Carbon project (https://github.com/briannesbitt/Carbon) is not very active anymore. The CakePHP team has forked the Carbon repo and created their own (that they also maintain and use in their own projects), called Chronos (https://github.com/cakephp/chronos).

Chronos aims to be a drop-in replacement for nesbot/carbon. It focuses on providing immutable date/datetime objects. Immutable objects help ensure that datetime objects aren't accidentally modified keeping data more predictable.

These are the differences between Carbon en Chronos

Differences with nesbot/carbon

The biggest and main difference is that Chronos extends DateTimeImmutable instead of DateTime. Immutability for date values has proven to be a great way of avoiding bugs and reduce the amount of code, since developers don't have to manually copy the instance every time they need a change.

Another important feature it offers is the Date class, which is used for representing dates without time (calendar dates). Any time method called on this type of object is basically a no-op.

A minor but still noticeable difference is that Chronos has no external dependencies, it is completely standalone.

Finally, Chronos is faster than Carbon as it has been optimized for the creation of hundreds of instances with minimal overhead.

Chronos also strives for HHVM compatibility, this library can be used safely with HHVM 3.11.

[brunogaspar]

Probably for Laravel 5.5 since Laravel 5.4 is right around the corner, but i would like to see this change regardless of the Laravel version.

[it-can]

It is a big change I think... It's sad that the Carbon project is not very active anymore

[michaeldyrynda]

"Inactive" or "feature complete"?

Either way, immutable dates would be appreciated 👌

[barryvdh]

But would be a big breaking change..

[sebastiandedeyne]

Maybe revisiting the improved type casting issue would be a better idea so it's opt-in. (I think most of the Carbon use is related to eloquent? Or am I missing a major section?)

#9

[hipsterjazzbo]

I've suggested this before, and been shot down. I think it's a great idea though.

1. Chronos seems to be much more maintained than Carbon
2. It is actually a lot more efficient for those of us that are doing hardcore large scale apps with Laravel
3. I personally find it a lot easier to reason about immutable dates, but I recognize that's not enough to justify the change in and of itself.

In terms of how big of a change it'd be, I agree it would have to be a 5.5 change. If anyone is interested I'd be happy to have a look at what'd need to be done to make it work.

In terms of people using Carbon in their business code, I feel like it'd be simple to just inform about the change and people can require Carbon\Carbon explicitly if they want.

[Garbee]

This would need to be like a 6.0 revision change. Modifying the way you provide dates and times from the DB layer is massive. Apps could rely on these being Carbon instances quite heavily throughout their application. This certainly isn't the level of thing you pawn off to just a regular upgrade.

Chronos seems to be much more maintained than Carbon

Can we define maintained here? What are major issues with Carbon that aren't being addressed? What about carbon (besides Mutability) is deficient?

Personally, I think the move would be good as well as I like immutable objects as well. However I'd like there to be more substance to a change this critical than "a few of us feel it is a good move." What is the actual benefit to Laravel in terms of long-term maintenance? What value is this providing to everyone using Laravel that they didn't have before?

[jbrooksuk]

If only we'd used the CarbonInterface https://github.com/cakephp/chronos/blob/master/src/carbon_compat.php

[jbrooksuk]

Actually, even Carbon isn't using that 😂

[lucasmichot]

Carbon is on its way to version 2.0 and a new release has been created past weekend.

[IonutBajescu]

@Garbee

What value is this providing to everyone using Laravel that they didn't have before?

Chronos is supposed to be faster than Carbon and have lower memory consumption. I'm saying "supposed" because I haven't actually benchmarked it myself and blindly trusted their readme, which says:

Finally, Chronos is faster than Carbon as it has been optimized for the creation of hundreds of instances with minimal overhead.

We'll obviously need to benchmark it ourselves though so we can see how relevant these speed changes are.

[tillkruss]

@it-can: Are you doing a PR for 5.5?

[it-can]

@tillkruss I am not working on a pr at this moment... seems though that carbon is getting active again...

[DanielDarrenJones]

Would defo like to see this be added, especially after learning about this "feature" of carbon: briannesbitt/Carbon#923

[lucasmichot]

This is neither a "feature", neither as bug as this is the way \Datetime works.
Still curious why nobody uses \Carbon\Carbon::addMonthsNoOverflow?