Handle DateInterval Roll-Over

[votemike]

It would be useful if there was a way to handle DateInterval Roll-Over. For example, I would hope that (ChronosInterval::seconds(107))->format('%I:%S') would output 01:47 rather than 00:107.

[othercorey]

Is there anything left to do on this?

[votemike]

I have just tested version 1.2.8 and dev-master and the rollover still happens.

[ADmad]

Guys this is an issue, not a pull request. So nothing has actually changed :slightly_smiling_face:.

[ADmad]

PR #172 does mention it could fix this issue but I guess that's not the case.

[othercorey]

@ADmad I'm aware it's an issue. That's why I was asking why it was still open if #172 handles the roll-over.

@votemike You are saying it is still working correct?

[votemike]

No. #172 does not fix the problem. My request remains open/valid/unfixed.

[othercorey]

Thanks for the clarification. I misunderstood the merged pull request then.

[ajibarra]

While having this at seconds, minutes, hours and days level could make sense, when weeks and months are involved it is impossible to actually know the amount of weeks or months without knowing the actual start date.

It will lead to bad calculations if you enter 35 days. According to this it should create an interval with 1 months and..5 days? but then if you add this interval to 05/15 the result will be 06/20 but if the interval would have been created as 35 days the result would be 06/19. That's the reason DateInterval base class works that way.

So again, it makes sense for seconds minutes and hours and it is something we could improve but I feel it does not make sense the effort while this is something that can be easily done at app level.

To summarize I think this issue can be closed.