On Thu, 9 Oct 2025 19:34:58 GMT, Pavel Rappo <[email protected]> wrote:
>> As specified and implemented, `Duration.plus(long amount, TemporalUnit)` >> does not make an exception for amount == 0. For any other value of month or >> years, the value is an estimate and the exception is thrown. >> It might be useful to consider a change (as a separate enhancement) > >> As specified and implemented, `Duration.plus(long amount, TemporalUnit)` >> does not make an exception for amount == 0. For any other value of month or >> years, the value is an estimate and the exception is thrown. It might be >> useful to consider a change (as a separate enhancement) > > I'm not sure that I completely understand what you are saying. Are you saying > that a zero of any unit is still zero and, if added, could result in the > initial instant rather than throw an exception if the unit is "incompatible" > with `Instant`? > > If so, then it reminds me of the following problem: should an unmodifiable > set allow to delete an element which it does not contain? Different APIs > decide differently. For example, this throws an exception: > > Set.of().remove(1) > > Whereas this doesn't: > > Collections.emptySet().remove(1) > > I don't know java.time deeply enough to lean one way or the other. But my gut > feeling tells me that unconditional exception is easier to reason about and > is more reliable. It was a suggestion for a different issue/PR. It could allow a Period that has months == 0 and years = 0 but a days != 0 to be added. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27549#discussion_r2433050354
