Framework: Enable new Carbon features on Laravel 5.6

Created on 27 May 2018  路  18Comments  路  Source: laravel/framework

  • Laravel Version: ~5.6.17

Description:

Hi, just a kindly reminder about new features in Carbon. We're often asked from Laravel 5.6 users about why some plugins or new features doesn't work for them. And the only way we have to help them is to give a composer cheat: "nesbot/carbon": "1.29.0 as 1.25.0". I understand the stability argument, but be aware we're now working on Carbon 2 and Carbon 1 will be now just maintained for bug fixes.

Here is the complete list of features that a "1.25.* || ^1.26.2" composer carbon version would allow in addition of third-party compatibility:

  • 1.29

    • Added CarbonPeriod and related methods in Carbon and CarbonInterval

  • 1.28

    • Added isStartOfDay, isEndOfDay, isMidnight, isMidday methods

    • Added locales bs_BA, hi, is, ne, oc, sh, sw

    • Added diff translations for ca, es, nl, no, pl, sl, sr*

    • Fixed ko, pl translations

    • Fixed createFromFormat with partial format and mock now instance

    • Added CarbonPeriod and related methods in Carbon and CarbonInterval

    • Added make methods to Carbon and CarbonInterval

    • Added getCascadeFactors, setCascadeFactors, getFactor, getDaysPerWeek, getHoursPerDay, getMinutesPerHours, getSecondsPerMinutes, cascade, total methods and total getters to CarbonInterval

    • Added $short argument to CarbonInterval::forHumans to display short formats

  • 1.27

    • Added isSameQuarter, isCurrentQuarter, isNextQuarter and isLastQuarter methods

    • Added isSameHour, isSameMinute, isSameSecond, isCurrentHour, isCurrentMinute and isCurrentSecond methods

    • Added CarbonInterval::times method

    • Added italian translation for diff words

  • 1.26

    • Added setDateFrom and setTimeFrom methods

    • Allowed DateTimeInterface in instance method

    • Added welsh language

    • Added CarbonInterval::getDateIntervalSpec (similar to CarbonInterval::spec but static and able to take any DateInterval instance as argument)

    • Added options for diffForHumans to support now/yesterday/tomorrow

Most helpful comment

Please, I want to use CarbonPeriod.

All 18 comments

The better solution is to create PR with requested changes...

The PR exists but was closed. So I prefer to expose first the new situation and discuss.

馃憤

I submitted a Carbon pull request today only to discover four package test cases are failing (unrelated to my change) because today is end of the month (and they don't consider https://github.com/briannesbitt/Carbon/pull/710 ). A date-handling package's test coverage is failing due to a change of date.

Carbon's recent release schedule:

  • 1.24.0 Mar 9, 2018
  • 1.24.1 Mar 9, 2018
  • 1.24.2 Mar 12, 2018
  • 1.25.0 Mar 20, 2018
  • 1.26.0 Apr 16, 2018
  • 1.26.1 Apr 16, 2018
  • 1.26.2 Apr 16, 2018
  • 1.26.3 Apr 16, 2018
  • 1.26.4 Apr 17, 2018
  • 1.27.0 Apr 23, 2018
  • 1.28.0 May 22, 2018
  • 1.29.0 May 24, 2018
  • 1.29.1 May 29, 2018
  • 1.29.2 May 29, 2018

Carbon was left dormant for awhile so it was seen as a stable product but since March the releases have been volatile, affecting projects in the Laravel ecoysystem. With trust in that dependency eroded, from my perspective it's more difficult to justify the maintenance burden when Laravel 5.6 is in a fairly good state now.

The test failure you mention is not related to new features. Carbon::now()->setMonth(9) (first test failing) does not always set the month to 3 (in case of overflow) and it's a native PHP DateTime behavior. This particular case happens when you go to a month when the current day does not exist. Those tests should be edited to cover this case but the Laravel 5.6 locked version 1.25.x is no different in this way from other versions. This behavior is not new, it's always been in Laravel.

Use ^1. is not mandatory, we could propose a range like >=1.26.2 <1.30 then time to time extend this range but just 1.25.* is very restrictive and make Laravel users open issues like "I cannot install this package (where a package require a earlier carbon version)", or "This method is in the documentation and I have the last Laravel 5.6 version but when I use it, it says the method is not found".

@derekmd I would argue that the actual cause of the failing tests is not overflow but weirdness of the create method - it defaults omitted units to the current date and time. This is however not a new behavior, but something that came with Carbon since the very first commit. Recent releases did not introduce a break, but contrarily exposed an existing oddity.

If your point was that mistakes shouldn't be made during the early 1.2x releases I don't think you chose a right argument. Please note that for some time Carbon was in fact not a stable product, but an unmaintained repo with very many open issues and prs. Mistakes can happen when a new maintainer takes over at a such point.

Edit: removed invalid rant

Maybe https://github.com/cakephp/chronos can serve as a replacement for Carbon? It was forked from it for the reasons other people already named here and should be compatible and it's maintained.

Chronos is cool and can easily be used instead by a simple settings change. But as the default library, it would be a bad idea. It is far from being compatible with current Carbon. And you say it's maintained but its last release is more than 1 year old while Carbon is now well maintained as its documentation. Carbon 2 will implement immutability and a better move would be to merge Chronos features into Carbon. If Chronos contributors want to join to the effort it would be with pleasure.

@kylekatarnls

its last release is more than 1 year

Chronos' last release was on 13. January 2018..

There is also a well enough maintained Chronos documentation, that could be extended, if necessary.

Chronos' last release was on 13. January 2018.

Sorry I looked "Latest release" as tagged by GitHub: https://github.com/cakephp/chronos/releases

But missed simple git tags.

And I did not said Chronos is not well maintained. But as @burzum said "and it's maintained", I would answer: as is Carbon, so it's not a reason enough to change the date library in Laravel and it's not at all the subject here. If you want to push Chronos in Laravel, you can open an other issue. Rather it would be done or not, as long as Carbon is a dependence of Laravel, if should be kept up to date. And that's the only point to debate here.

I have really nothing against Chronos. The point is that Laravel's users comes to Carbon issues and Carbon library repositories facing compatibility issues due to the gap between 1.29 documentation and 1.26+ plugins and the current Laravel 5.6 restriction.

It would be great get carbon 1.29.
In my case I need it, beacuse I want to use the carbonPeriod feature, its really important to my project.

Really would love to get carbon 1.29 for the CarbonInterval::cascade(). Tired of stuff like this:
$anyTime = Carbon::now();
return CarbonInterval::instance($anyTime->copy()->add($runtime)->diff($anyTime));

Please, I want to use CarbonPeriod.

@taylorotwell What about "nesbot/carbon": "1.25.* || >=1.26.2 <1.30" which would not auto-update on 1.30 release?

Laravel 5.6 is fixed to Carbon 1.26 due to various breaking and incompatible changes, Laravel 5.7 is due soon and have the latest version pulled.

@themsaid No, it's fixed to 1.25 and it's not incompatible, any version after 1.26.1 can be used as 1.25.09 with no incompatibilities. The 2 breaks that happened had been fixed in a couple of hours. In fact last time the fix came before Laravel released the 1.25.* freeze. So there is no particular reason to freeze Laravel 5.6 when you can either use a update-safe range or simply align Laravel 5.6 on 5.5 and 5.7 versioning.

I'm pretty sure we can do something more precise.

You can install the latest version of Carbon with Aliasing in composer.json

"nesbot/carbon" : "2.3 as 1.26.3"

Was this page helpful?
0 / 5 - 0 ratings