Carbon use parse method

[florisbosch]

Yesterday I made a pull request (#6176) to fix some extra cases for add / sub hours, minutes and seconds.

This fix wasn't reliable enough since the amount of options you can specify in \DateTime is much more than what we have now. To fix this problems we can use the parse method in Carbon this should be an drop-in replacement of \DateTime.

I think it's best to start with this for now our base Carbon ruleset.
In future releases we can extend this and create extended sets to convert to Carbon specific functions like addX and subX but only if all cases are handled.

Also this change now includes specific times that have been set and if we have a rest string for the date we change the original static call to a parse

[samsonasik]

Another solution is limit the possible values passed as arg, and skip transformation if not match yet, so the existing functionality not changed, if there is different arg pattern, it should be skipped instead to be added later

[florisbosch]

@samsonasik You are correct. It's better to keep the existing add/sub in case the regex matches.
I've changed this a bit to make it easier to support other formats in the regex.
When we don't have a match we can fallback on the parse function.

[florisbosch]

Hey @TomasVotruba,

The CI now passes. I had some trouble running this locally so had to push a few times 😄

Basically it can now create a correct carbon date for most common cases and what we cannot parse to a correct Carbon method we let their native parse function handle.

Can you review this PR?

Had some trouble by changing the first static call I solved this by using references but this didn't pass the static tests.
Now I rebuild the carbon call from a call stack. I'm not quite sure about this solution maybe you have some better idea for this? Feel free to make a change.

[florisbosch]

@TomasVotruba i.m.o it might be better to not use the setDate, setTime & setDateTime functions like I have now and just handle those with parse.

when I have a date like

 $date = new \DateTime('2024-01-02');

I rather have this as the result

 $date = \Carbon\Carbon::parse('2024-01-02');

Instead of what I do now

 $date = \Carbon\Carbon::now()->setDate(2024, 1, 2);

Having the parse functionality is most neat with the original and is better for creating dates
What do you think?

[TomasVotruba]

Having the parse functionality is most neat with the original and is better for creating dates

Looks good! It's also keep original format, that makes is more smoother to migrate to

[florisbosch]

@TomasVotruba, It is now done for review/merge, I removed the setDate & setTime function.

I've also added an extra configure rule to this ruleset, this will Rename new \DateTime to new \Carbon\Carbon for cases where the argument is not a string, but might be another date object.

[TomasVotruba]

Looks good!

@florisbosch Thank you for your amazing work 👏