Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
if I'm using Carbon in my web app, should I:
a) implicitly use Carbon\Carbon as the laravel framework already includes it as a dependency or
b) use Illuminate\Support\Carbon or
c) explicitly composer require nesbot\carbon and use Carbon\Carbon?
a and b breakdown if Laravel ever removes it as a dependency
Here is the difference between a/b https://laravel.com/api/5.5/Illuminate/Support/Carbon.html
I personally vote for a.
And if the package is removed from laravel, it would definitely be a breaking change, so I don't think it will be ( at least any time soon)
I believe \Illuminate\Support\Carbon just wraps Carbon\Carbon now for backwards compatibility - since the Carbon\Carbon package now implements the things (macroable) that the Laravel implementation was solving
@tykus That would indicate that a future release might remove the wrapper, right?
I expect so, yes.
@tykus it is 2022 and I still see \Illuminate\Support\Carbon.
@franciscocaldeira yes? If it was removed alot of apps would probably break. Does it matter that it's there? If you want it gone, you could try adding a pr to laravel 9
@Sinnbeck it matters if you're working on a large team that now has to just hope everyone remembers to use the correct one or risk bugs with function type declarations.
@DigDoug what kind of invalid reasoning is this? it is the same as saying you need to remember to use App\Models\User, instead of Illuminate\Foundation\Auth\User. use it or not 🤷♂️
IDE nowadays helps a lot, and if you have concerns about someone in your team using both/wrong one, just use some tool to prevent it (https://phpstan.org/developing-extensions/rules or https://pestphp.com/docs/arch-testing#expect-toBeUsed) and integrate it into your code-quality workflow or pipeline
@franciscocaldeira well, if you bothered to look into the source, you will see that Illuminate\Support\Carbon is no longer an empty wrapper for Carbon\Carbon (as it was whenever I wrote the original reply 5 years ago). Things change... roll with it. Or, just drop back in another 2 years with a follow-up.
@tykus I had a look and it adds nothing meaningful, so I don't really see your point.
https://github.com/laravel/framework/blob/12.x/src/Illuminate/Support/Carbon.php
It's actually better to use Carbon\Carbon because if you work with CarbonImmutable (which you always should, by default) and you make a mutable version using ->toMutable() it will create an instance of Carbon\Carbon.
Having some instances being one and others being another is a silly idea.
Please or to participate in this conversation.