Stop using Carbon? #6509

Closed
lorenzo opened this Issue May 7, 2015 · 27 comments

Comments

Projects
None yet
@lorenzo
Member

lorenzo commented May 7, 2015

I went to the Carbon project to see what's new there and found this jewel:

https://github.com/briannesbitt/Carbon/blob/master/composer.json#L21

As it stands now I'm not too happy with our dependency on carbon for several reason:

  • We have failed a communicating the API that is available
  • Bugs are fixed at a slow pace
  • It could definitely be faster
  • Introduces a big chain of dependencies

I also have some ideas of how it could be done better:

  • Move all methods to a trait
  • Implement our own DateTime (and in the future DateTimeImmutable) using the trait
  • Reduce internal method calls that make it slow
  • Offer I18n as a separate thing as we already do.

This will also give us the excuse to properly document the API in our docs.

@lorenzo lorenzo added the RFC label May 7, 2015

@lorenzo lorenzo added this to the 3.1.0 milestone May 7, 2015

@josegonzalez

This comment has been minimized.

Show comment
Hide comment
@josegonzalez

josegonzalez May 7, 2015

Member

Can we offer this as a standalone datetime library? Is there an alternative to carbon that we can use?

Member

josegonzalez commented May 7, 2015

Can we offer this as a standalone datetime library? Is there an alternative to carbon that we can use?

@lorenzo

This comment has been minimized.

Show comment
Hide comment
@lorenzo

lorenzo May 7, 2015

Member

That was my idea @josegonzalez

Member

lorenzo commented May 7, 2015

That was my idea @josegonzalez

@dereuromark

This comment has been minimized.

Show comment
Hide comment
@dereuromark

dereuromark May 7, 2015

Member

Awesome idea. Just what I had in mind from the beginning :) Carbon was a great library, but yeah, way too slow pace and not necessarily going in the right directions. Having a cakephp/carbon, cakephp/time or sth is the way to go 👍

With such a strong community behind it, it will soon outrun carbon as the de-facto standard.

Member

dereuromark commented May 7, 2015

Awesome idea. Just what I had in mind from the beginning :) Carbon was a great library, but yeah, way too slow pace and not necessarily going in the right directions. Having a cakephp/carbon, cakephp/time or sth is the way to go 👍

With such a strong community behind it, it will soon outrun carbon as the de-facto standard.

@markstory

This comment has been minimized.

Show comment
Hide comment
@markstory

markstory May 8, 2015

Member

I am ok with forking carbon and optimizing/simplifying the internals. Reimplementing an API compatible alternative is also a good option and would allow us to provide immutable variants like @lorenzo mentioned.

In either scenario we should aim to have a library with 0 dependencies.

Member

markstory commented May 8, 2015

I am ok with forking carbon and optimizing/simplifying the internals. Reimplementing an API compatible alternative is also a good option and would allow us to provide immutable variants like @lorenzo mentioned.

In either scenario we should aim to have a library with 0 dependencies.

@kicaj

This comment has been minimized.

Show comment
Hide comment
@kicaj

kicaj May 9, 2015

Contributor

👍 for @lorenzo idea:)

Contributor

kicaj commented May 9, 2015

👍 for @lorenzo idea:)

@jadb

This comment has been minimized.

Show comment
Hide comment
@jadb

jadb May 9, 2015

Member

👍 just because it started relying on other dependencies.

Member

jadb commented May 9, 2015

👍 just because it started relying on other dependencies.

@sukihub

This comment has been minimized.

Show comment
Hide comment
@sukihub

sukihub May 9, 2015

Contributor

👍 for immutable Time (I just hate that I have to ->copy() it every time I want to add an hour or change the timezone or ...). I'm however not a big fan of creating yet another PHP (DateTime) library. We all would benefit from 1 really good DateTime library more than from 5 poor ones. Can't we just contribute to Carbon? Maybe suggest them to split it into two libraries (core and i18n stuff)?

Contributor

sukihub commented May 9, 2015

👍 for immutable Time (I just hate that I have to ->copy() it every time I want to add an hour or change the timezone or ...). I'm however not a big fan of creating yet another PHP (DateTime) library. We all would benefit from 1 really good DateTime library more than from 5 poor ones. Can't we just contribute to Carbon? Maybe suggest them to split it into two libraries (core and i18n stuff)?

@dereuromark

This comment has been minimized.

Show comment
Hide comment
@dereuromark

dereuromark May 9, 2015

Member

@sukihub The problem so far was that is was a one-man show with months (> 4 even with critical bugs) of activity break, which is unacceptable for such a widely used library of that magnitude IMO.
We reached out multiple times in the past, offered help and even co-management. To be fair, it got better, but it is still far from ideal. Thus branching off might be a justified solution.

Member

dereuromark commented May 9, 2015

@sukihub The problem so far was that is was a one-man show with months (> 4 even with critical bugs) of activity break, which is unacceptable for such a widely used library of that magnitude IMO.
We reached out multiple times in the past, offered help and even co-management. To be fair, it got better, but it is still far from ideal. Thus branching off might be a justified solution.

@sukihub

This comment has been minimized.

Show comment
Hide comment
@sukihub

sukihub May 9, 2015

Contributor

@dereuromark Oh, I guess I just never imagined that somebody wouldn't want help with an open-source project, silly me :-) Glad to hear you already tried that and sorry I kinda doubted you :-)

Contributor

sukihub commented May 9, 2015

@dereuromark Oh, I guess I just never imagined that somebody wouldn't want help with an open-source project, silly me :-) Glad to hear you already tried that and sorry I kinda doubted you :-)

@zoghal

This comment has been minimized.

Show comment
Hide comment
@zoghal

zoghal May 10, 2015

Contributor

👍 good idea

Contributor

zoghal commented May 10, 2015

👍 good idea

@ionas

This comment has been minimized.

Show comment
Hide comment
@ionas

ionas May 12, 2015

Contributor

The fewer dependencies the better.
If at the same time you CAN decouple things without having to add too much glue, great.

Contributor

ionas commented May 12, 2015

The fewer dependencies the better.
If at the same time you CAN decouple things without having to add too much glue, great.

@markstory

This comment has been minimized.

Show comment
Hide comment
@markstory

markstory May 12, 2015

Member

@ionas I wouldn't expect any more glue than we currently have with carbon.

Member

markstory commented May 12, 2015

@ionas I wouldn't expect any more glue than we currently have with carbon.

@davidyell

This comment has been minimized.

Show comment
Hide comment
@davidyell

davidyell May 28, 2015

Contributor

As long as it doesn't break BC, I'm 👍

Contributor

davidyell commented May 28, 2015

As long as it doesn't break BC, I'm 👍

@burzum

This comment has been minimized.

Show comment
Hide comment
@burzum

burzum May 28, 2015

Member

👍

Member

burzum commented May 28, 2015

👍

@ravage84

This comment has been minimized.

Show comment
Hide comment
@ravage84

ravage84 May 31, 2015

Member

Sad to see this failing, but 👍

Member

ravage84 commented May 31, 2015

Sad to see this failing, but 👍

@drmonkeyninja

This comment has been minimized.

Show comment
Hide comment

👍

@andrecavallari

This comment has been minimized.

Show comment
Hide comment
@andrecavallari

andrecavallari Jun 8, 2015

So... will this standalone lib be created?

Using CakePHP 3.0 with PHP7 I get this error:

Warning (2): Declaration of Carbon\Carbon::createFromFormat() should be compatible with DateTime::createFromFormat($format, $time, DateTimeZone $object = NULL) [ROOT/vendor/nesbot/carbon/src/Carbon/Carbon.php, line 2203]

I fixed it my own hand, but just want to know more about this standalone plugin

So... will this standalone lib be created?

Using CakePHP 3.0 with PHP7 I get this error:

Warning (2): Declaration of Carbon\Carbon::createFromFormat() should be compatible with DateTime::createFromFormat($format, $time, DateTimeZone $object = NULL) [ROOT/vendor/nesbot/carbon/src/Carbon/Carbon.php, line 2203]

I fixed it my own hand, but just want to know more about this standalone plugin

@lorenzo

This comment has been minimized.

Show comment
Hide comment
@lorenzo

lorenzo Jun 8, 2015

Member

it will, when someone gets the time to do it. Maybe you are interested @andrecavallari ?

Member

lorenzo commented Jun 8, 2015

it will, when someone gets the time to do it. Maybe you are interested @andrecavallari ?

@andrecavallari

This comment has been minimized.

Show comment
Hide comment
@andrecavallari

andrecavallari Jun 8, 2015

I already started something here, if it works I will share it

I already started something here, if it works I will share it

@lorenzo

This comment has been minimized.

Show comment
Hide comment
@lorenzo

lorenzo Jun 8, 2015

Member

great!

Member

lorenzo commented Jun 8, 2015

great!

@lorenzo

This comment has been minimized.

Show comment
Hide comment
@lorenzo

lorenzo Jun 14, 2015

Member

@andrecavallari any progress on this?

Member

lorenzo commented Jun 14, 2015

@andrecavallari any progress on this?

@andrecavallari

This comment has been minimized.

Show comment
Hide comment
@andrecavallari

andrecavallari Jun 15, 2015

Not yet, still using Carbon ;(

Not yet, still using Carbon ;(

@sdustinh

This comment has been minimized.

Show comment
Hide comment
@sdustinh

sdustinh Jun 15, 2015

Contributor

I haven't looked into this at all (just casually commenting on an issue in my notifications) but if we are kicking around RFC ideas I would love support for the FormHelper datetime format in the API Instantiation so something like this would be easier...

public function validationDefault(Validator $Validator)
{
    return $Validator
        ->add('expires', [
            'in-future' => [
                'rule' => function ($value, $context) {
                    /*
                    $value = [
                        'year' => '2015',
                        'month' => '06',
                        'day' => '15',
                        'hour' => '19',
                        'minute' => '22'
                    ];
                    */

                    return $value->isFuture();
                },
                'on' => function ($context) {
                    return !empty($context['data']['expires']);
                },
                'message' => 'Expiration must be set to a future date.'
            ]
        ]);
}
Contributor

sdustinh commented Jun 15, 2015

I haven't looked into this at all (just casually commenting on an issue in my notifications) but if we are kicking around RFC ideas I would love support for the FormHelper datetime format in the API Instantiation so something like this would be easier...

public function validationDefault(Validator $Validator)
{
    return $Validator
        ->add('expires', [
            'in-future' => [
                'rule' => function ($value, $context) {
                    /*
                    $value = [
                        'year' => '2015',
                        'month' => '06',
                        'day' => '15',
                        'hour' => '19',
                        'minute' => '22'
                    ];
                    */

                    return $value->isFuture();
                },
                'on' => function ($context) {
                    return !empty($context['data']['expires']);
                },
                'message' => 'Expiration must be set to a future date.'
            ]
        ]);
}
@wisamhussain

This comment has been minimized.

Show comment
Hide comment
@wisamhussain

wisamhussain Jul 30, 2015

A standalone CakePHP Date/Time library with 0 dependencies would be ideal.

A standalone CakePHP Date/Time library with 0 dependencies would be ideal.

@dereuromark

This comment has been minimized.

Show comment
Hide comment
@dereuromark

dereuromark Aug 19, 2015

Member

With #7263 limitation it is even more important to speed up this process IMO to avoid bugs being production-blockers as we cannot use the newer bugfix versions.

Member

dereuromark commented Aug 19, 2015

With #7263 limitation it is even more important to speed up this process IMO to avoid bugs being production-blockers as we cannot use the newer bugfix versions.

@markstory markstory modified the milestones: 3.1.0, 3.2.0 Aug 26, 2015

@lorenzo

This comment has been minimized.

Show comment
Hide comment
@lorenzo

lorenzo Nov 22, 2015

Member

@markstory is there anything missing before closing this?

Member

lorenzo commented Nov 22, 2015

@markstory is there anything missing before closing this?

@markstory

This comment has been minimized.

Show comment
Hide comment
@markstory

markstory Nov 22, 2015

Member

Nope.

Member

markstory commented Nov 22, 2015

Nope.

@markstory markstory closed this Nov 22, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment