Invalid CarbonInterval->format() results for Carbon 3 (unknown). about carbon

[kylekatarnls]

Carbon is provided to you for free, we never made any promise that Carbon v2 would be compatible with whatever Symfony version that would come in the future.

The reasons why diff* methods are changing have been explained and warned ahead as the main change for v3, I won't repeat this part. And it's anyway too late for that.

fix consequences of your decisions at Carbon.

Please keep it respectful, people put hard work on this project and you get it for $0.

If you think it does not worth the time you have to spend on it, you're free to build you own not-ridiculous library to make your company development.

Also it's open-source, you can propose a fix for this specific issue about ->format().

[kylekatarnls]

this changes are discussed by many and considered as drastic

Yes, and all those complains happened in a short period, but for years, a ton of complains about the Carbon v2 behavior of the diff methods also accumulated and for reasons. And it is healthy, on major bump to rework such pain points and reconsider what makes sense.

Am I not legitimate to criticize decisions made

Let's step back on this as I'm not sure what decision we're talking about. If we hadn't touched the library at all during the last 2 years, you would not be able neither to use Carbon with Symfony 7, so when you say you have those 2 options:

• do not update framework and stay on C2
• upgrade framework and Carbon with all the consequences

By actually making the Carbon 3 version you have the second option and while we have few reports we also have a lot of download of silent users (so assuming satisfied with this option), without the "decision" taken to work on this new version, you would just be stuck with the 1 option:

• do not update framework and stay on C2

No one removed an option from you. Using Carbon 2 with Symfony 7 just never has been possible.

We just decide not to work on this particular path.

Am I not legitimate to criticize decisions made just because it is open source?

With all the users we have, any decision and its opposite decision will always make some of them unhappy.

You can still complain but for the reason above and the fact we own nothing to companies using our libraries, we'll not use that as an reliable indicator of either changes are good or not for the majority of our users and so, this is likely not having any useful impact.

On the other side, you can fork Carbon v2 branch, and try to make your own way to make it compatible with Symfony 7 without picking the Carbon 3 changes.

BTW it will be way more easy for you because you won't have to keep any backward compatibility with older Symfony and PHP versions, keeping minor versions backward-compatible is providing stability to users (within a given major version) but is putting a lot of burden on maintainers.

[kylekatarnls]

So I took the path to override format, ->days will still not be usable, but ->format('%a') will returns (once #3031 is merged and 3.3.1 released) what DateInterval::format would have returned as soon as the interval was created from a diff().

[kylekatarnls]

Hello,

I will investigate if we can put back this support and keep the other benefits of CarbonInterval, for the record, in Carbon v2 diff was giving a DateIntervaln in v3, it's now equivalent to the v2 diffAsCarbonInterval method, and this object is not directly created from the diff so miss the total number of days at the moment.

However you can work around this for now using:

$past = new CarbonImmutable('-3 Days');
$today = new CarbonImmutable('today');
$interval = $today->diffAsDateInterval($past);

[jifer]

We have huge project that heavily relays on Carbon almost everywhere. Including twig where such workarounds are hard to achieve (like "just" putting (int) in front of diffInDays).

Upgrading to Symfony 7 and all other libraries took 1% time.
Upgrading Carbon to 3 took 99% and is still ongoing because you forces us to upgrade from 2 which has many braking changes including such trivial thing as above. Our base code already have thousands of updated lines because all things you did with diff* methods. You did something very dangerous from our company perspective. Changes done to C3 may create bugs in unexpected places without warning because of processing 1.23 instead of 1 or (int) '(unknown)' instead of (int '2').
This are bugs that should never occur and occur in most unpleasant way: by searching why you have all your data wrong on the database and how to fix that after 2 months of working on production.

This is more than ridiculous that library extending DateTime is preventing us from framework upgrades or force us to invest huge amount of time to create workarounds.

And yes, above post is dictated by frustration of someone who already spent hours trying to fix consequences of your decisions at Carbon.

[jifer]

First of all, please take my apologies. I didn't ment to disrespect anyone. I do have full respect for anyone working for community purpose and open source liblaries.

I do know reasons why diff changes was introduced. But also It is noticable that this changes are discussed by many and considered as drastic.
We, as users, put our trust in project like this and we choose such free solution to help us in our day to day task. After years of using Carbon in specific project it is really hard to change such library. Thus it is hard to get over that we was forced to take this approches:

• do not update framework and stay on C2
• upgrade framework and Carbon with all the consequences

Am I not legitimate to criticize decisions made just because it is open source? Maybe not. But i did.

---

About the issue. I did some research before posting.

%a is based on $days which is set while using diff method on \DateTime instance. diffAsCarbonInterval is not using core diff method (and that understandable).
\DateInterval instance created by constructor has $days = false.
But you already know all of this considering this comment from CarbonInterval::instance

     * Create a CarbonInterval instance from a DateInterval one.  Can not instance
     * DateInterval objects created from DateTime::diff() as you can't externally
     * set the $days field.

Maybe someone knowing this library better than me (or smarter than me) will find better solution than overriding format method to use other parameter than days to display %a result.

With best regards.

[jifer]

Thank you for your time to respond.
Hope someone will find way to fix above. I do prefer to be on time with libraries thus we will take time to upgrade all places with workarounds or other methods.

With regards.

[jifer]

Seeing PR im glad I didn't do it by myself. Without knowing library and its nuances my resolution wouldn't be fully correct. Thank you for fix & your support.