Is this project still alive?

[tpraxl]

Given the amount of PRs and issues, failing travis setups and the last commit being exactly Carbon::now()->subYear(1)… is this project still alive?

@briannesbitt are you planning to continue maintaining Carbon?

Please let us know. This project is a great piece of work and it deserves continuous maintenance. If you are currently not able to maintain the project, maybe there are others willing to help?

[GwendolenLynch]

The short version is that Brian has the passion, but a family to feed and a business to run so certain priorities need to be balanced for him, and IMO this is 100% fair.

I've spoken with Brian on one occasion and was trying to negotiate just that with him, as I run a medium-sized project that uses this library extensively. The delay in negotiations had me set up a forked project carbondate/carbon as it is critical to real business needs for our users (and I'm happy to onboard new contributors).

The CakePHP team have also evolved this project into another library (Chronos) if that suits one's needs.

[Glavic]

@GawainLynch first thing you should do is remove the following function:

https://github.com/CarbonDate/Carbon/blob/caeb2405274b46e1233004a3c58dfdb93b755b19/src/Carbon/Carbon.php#L3328

[tpraxl]

IMO this is 100% fair.

I share your opinion. I'll have a look at both carbondate/carbon as well as cakephp/chronos. Thanks for the hints. And thanks to @briannesbitt for his great work.

[GwendolenLynch]

@Glavic what is the reasoning? For reference, it was was introduced in response to #88

[Glavic]

@GawainLynch modify() method is not the problem, but diffInHours() seems to be:

$a = new Carbon('2014-03-30 00:00:00', 'Europe/London');
print_r($a);

$b = $a->copy();
$b->addHours(24);
print_r($b);

print_r( $a->diff($b) );         # returns 1 day
print_r( $a->diffInHours($b) );  # returns 23 hours ... why :)

They solved that issue all wrong. Modify method should never be solved like it was.

p.s. this is how I would fix this issue: https://github.com/Glavic/Carbon/commit/97d26223f737b445903daead844b1a506dd46401

[kylekatarnls]

Hi @Glavic do you mean this has been fixed in PHP 7.2? Because Carbon is not tested with PHP 7.2 so it could not yet guarantee the compatibility.

[GwendolenLynch]

carbondata/carbon runs CI on PHP 7.2 & nightly so it isn't there.

Something is quirky, I just have the worst days of the flu hitting me, so stepping slowly through it right now

[Glavic]

@kylekatarnls: Carbon is tested on >=5.3, you can see here that my commit passes all tests.

[GwendolenLynch]

@Glavic this doesn't seem to be a Carbon specific problem

$a = new DateTime('2014-03-30 00:00:00', new DateTimeZone('Europe/London'));
print_r($a);

$b = clone $a;
$b->add(new DateInterval('PT24H'));
print_r($b);

print_r($b->getTimestamp() - $a->getTimestamp());

For me will output 82800 as the last print_r, which is 23 hours. If I had to guess, we're both in CET or equivalent time zones, and the clone doesn't take into account the cast zone properly. (but see above about the state of my head right now :rofl: )

[Glavic]

@GawainLynch : like I already said, diffInHours() or diffInSeconds() method is the problem, because it is doing calculations with timestamp, like you demonstrated, and this is not how you do datetime diff...

See my commit: Glavic/Carbon@97d2622, it passes all the tests

[GwendolenLynch]

Thanks, @Glavic … I've added a PR with your commit and will have a better look at it in the morning — https://github.com/CarbonDate/Carbon/pull/27

[kylekatarnls]

@GawainLynch I will probably migrate to carbondata/carbon. Build tests on PHP 7.2 is important to me, you also should add it in your README badge.

@Glavic Well done! I was not very happy to override the DateTime::modify method. 4 years later at least a good solution!

[Glavic]

@kylekatarnls: aaaaa, you were the one to blame for that method :) If you believe me, I have never looked at the owner of that piece of code :)) Too bad no moderators are here :(

@GawainLynch: I didn't even knew that you can create PR with some1 else's commit 👍

[kylekatarnls]

No, it was not my code. I proposed the modify override (a fix that worked for me). Never merged, one year later, a fix not as bad as mine but altering modify method too has been merged instead. And this code never changed again.

Git allow you to use any name/email as author and committer and by default, when rebase or cherry-pick, author is kept, committer is changed.

And it's not a matter of moderation. When users have a bug, a working solution is better than no solution.

But you're not the only one bothered by this: https://github.com/briannesbitt/Carbon/pull/1070/files

[simonschaufi]

@GawainLynch If Brian has no time for it, why didn't he just give you write access to this repo? This project has at the moment 40 324 641 installations on packagist. What a huge responsibility!

Some people like me are just waiting for symfony 4 compatibility ;)

[GwendolenLynch]

@simonschaufi carbondate/carbon has SF4 compatibility. That was literally the thing that was the deciding factor for us to branch off CarbonDate.

As for why not … well, that was discussed, but he's a busy person who has put a lot into the project. I think until he has the time and inclination to invest in this repository all we can do is raise a glass and say thank you :smile:

[simonschaufi]

yes, I'm using your fork now but I try to avoid forks as much as possible.

well, that was discussed, but he's a busy person

that should be a good reason to give the project in other good and trustful hands. ;)

[Glavic]

I volunteer to be collaborator/moderator of this project :)

ping @briannesbitt

[kylekatarnls]

I agree with @simonschaufi, it's too bad a such great project become unmaintained ; as far as I'm concerned, I stopped to contribute to Carbon because of the delay before merge/answer. If @briannesbitt would agree to add contributors, the different forks could merge again and provide a "universal" standard date library. Laravel users would start with an up-to-date package installed and less users would have to switch to an other dependency.

I think historical contributors (such as @lucasmichot or @GrahamCampbell) could be interested as well as developers who start forks and pull request like @Glavic or @GawainLynch maybe. I would be glad to participate too.

Would be nice to team up around a slack. What do you think about? Hope we'll get some news of @briannesbitt, I'll try to reach him.

[GrahamCampbell]

I'm not interested in taking on any more maintenance I'm afraid.

[briannesbitt]

Hey guys ! Thanks for taking the time to comment in here.

I haven't had nearly the time that Carbon deserves. I added Lucas awhile ago to the maintainers list to help move it along, but he seems to have dropped off as well :-(

The other large contributing factor is I don't work with PHP any more and maintaining a library that I don't personally use I always find challenging.

I still can't believe I started Carbon 5 years ago !

I am definitely open to adding a small group of contributors to this repo to keep it alive.

[bobdenotter]

Hi @briannesbitt,

Good to hear from the project's starter.

I don't work with PHP any more and maintaining a library that I don't personally use I always find challenging

In that light, I'd like to put in my voice with others suggesting that Carbon should be moved to an "org", instead of keeping it tied to your personal repository. Having the project in an org will show to outsiders that there's a renewed effort in the project, making people confident that Carbon will be maintained for a long time.

[simonschaufi]

@gawainlynch: would you be willing to maintain this repo?

[lorenzo]

The CakePHP project is maintaining the Chronos project (https://github.com/cakephp/chronos/) as a more modern Carbon. It is easy to migrate to it too. My personal suggestion would be to consolidate maintenance efforts in Chronos.

[simonschaufi]

The thing is, Laravel depends on this version: https://github.com/laravel/framework/blob/5.6/composer.json#L26 (~40.000+ Stars on github (laravel/laravel) and 35 million installations)

[bobdenotter]

@simonschaufi Both the git repository and the composer package can be updated, which will make the transition for the end user seamless.

[kylekatarnls]

Hi @bobdenotter are you talking about changing the repository URL of netsbot/carbon to link to https://github.com/cakephp/chronos/? This seems very confusing to me.

And you also have to change the PHP code since, Chronos use other namespaces and class names.

An other approach would be to have a base project and other project that require it and extend the base class. This would save maintenance efforts.

And I'm not so agree with the @lorenzo sentence "It is easy to migrate". I can identify multiple points that would block some implementations/users:

• PHP 5.3 and 5.4 compatibility: I perfectly understand why Chronos dropped them but any depedent project which want/must support those versions or end-users running this versions just can't migrate.
• Chronos has its own version numbers, so carbon: ~1.20 will simply just break.
• The default Chronos class is immutable. Immutable is cool, but all existing apps using Carbon add, sub, modify must use MutableDateTime and so provide backward compatibility would mean having Carbon\Carbon extends Cake\Chronos\MutableDateTime too bad to migrate to a immutable-by-default library if we need to mutable it.

You can consider it's easy enough to migrate for one end-user who deals with his compatibility problems, but @simonschaufi is right, it's not for a project that want to ensure updates with no breaking changes for existing apps that does not require the library directly (and I'm not speaking just of Laravel 5.6, I'm speaking of 899 dependent projects https://www.versioneye.com/php/nesbot:carbon/references and all versions of all that projects).

It seems feasible that next Laravel version would use an other library than Carbon, nevertheless, there would be still many Carbon-users to support until they progressively upgrade/migrate. I have nothing against Chronos, but Carbon version 1 deserve maintenance efforts and updates too.

[GwendolenLynch]

No, @bobdenotter is referring to moving Carbon to an org, namely CarbonDate. We're supporting a couple of thousand sites on CD already, and have to maintain that for years to come. Regardless of this discussion, we have large paying customers that need their sites to be maintained. Shiny numbers mean little past that.

Simply bus factor is a massive problem here. Brian will respond (currently) once every three months. We have product needs, infrastructure and combined experience of several decades maintaining OSS projects.

We're proposing:

• Make the org the canonical source
• Modify the URL on Packagist
• Continue to onboard maintainers who are capable
• Chill pills for everyone

There is a staffed and supported Carbon v1, it just doesn't live here any longer, and is already quite the delta: https://github.com/CarbonDate/Carbon/compare/1.22.1...1.23 (tests, translations, PHPStan level 7, etc)

A consolidation of effort would be great, but we are not seeing that happening currently.

[Glavic]

Like I already said, I volunteer to be collaborator of this project. Before you all made up what you wish to do, I could clean up issues and PR's...

[bobdenotter]

@kylekatarnls I was indeed referring to moving it to https://github.com/CarbonDate/Carbon. It functions as a drop-in replacement for briannesbitt/Carbon. 100% compatible, just with fixed bugs and more up-to-date.

I can't speak for the Laravel community, but I assume it would be vastly preferable to do a seamless transition, than one that introduces breaking changes for the entire Laravel ecosystem.

Thoughts, @taylorotwell ?

[kylekatarnls]

Hi @simonschaufi I started a Slack with some e-mail addresses I was able to find but I didn't find yours.

So for everyone who would request an access to the Slack, I did a quick form to send privately your e-mail address: http://carbon.selfbuild.fr/

[simonschaufi]

I don't see the need of being part of the discussion. I just hope that someone is willing to keep this project alive. I don't have time to maintain another library. Too many projects already...

[briannesbitt]

As you can see by the recent activity I have brought @kylekatarnls and @Glavic on as contributors to the project. This was the easiest and quickest way to get the project moving again in the right direction. Thank you to the both of them for stepping up and their work so far !