Fix int overflow in DurationFormatUtils.formatPeriod

[alhudz]

Thanks for your contribution to Apache Commons! Your help is appreciated!

Before you push a pull request, review this list:

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute?
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.

---

Repro: DurationFormatUtils.formatPeriod(0, 2175984000000L, "s", true, gmt) for a ~69 year span (gmt is TimeZone.getTimeZone("GMT")).
Expected: 2175984000, the value the sibling formatDuration(2175984000000L, "s") returns for the same span.
Actual: -2118983296.

Cause: formatPeriod keeps its day/hour/minute/second estimates in int. When the format omits a higher field, that field is funnelled into the next lower one (hours += 24 * days, minutes += 60 * hours, seconds += 60 * minutes) in int arithmetic before the values widen to the long parameters of format. Past a few decades the second (or millisecond) count exceeds Integer.MAX_VALUE and the multiply wraps negative.

Fix: declare the six estimate locals as long so the reduction runs in long, the same way formatDuration already reduces the span. milliseconds was already long; normal-size durations produce identical output.

[garydgregory]

Hello @alhudz

Thank you for the PR.

Would you please add a tests that:

• asserts that the right formatting happens for inputs around and at Long.MAX_VALUE, for example the duration starting at Long.MAX_VALUE -1 and ending at Long.MAX_VALUE.
• Same for Long.MIN_VALUE
• Same for Integer.MIN_VALUE

This should hopefully show that we can correctly handle the full range of long millisecond values for the input to this method.

TY!

[alhudz]

Added testFormatPeriodLongRangeBounds, which runs a one-millisecond span at each end of the input range:

• Long.MAX_VALUE - 1 .. Long.MAX_VALUE
• Long.MIN_VALUE .. Long.MIN_VALUE + 1
• Integer.MIN_VALUE - 1 .. Integer.MIN_VALUE

Each one asserts S is 1, the full y/M/d/H/m/s.S is 0/0/0/0/0/0.001, and that formatPeriod matches formatDuration for the same span, so the reduction holds across the whole long range and not just spans near the epoch. DurationFormatUtilsTest is green (37 tests).