I agree that it would be weird for Duration.MIN not to be the true minimum Duration value, and that weirdness outweighs the quirk whereby Duration.MIN.negated() throws an exception.
[It's much too late to do anything about it now, of course, but I would argue that it would have been better for Duration values to be completely symmetrical about zero. I think the parallel with Long.MIN_VALUE (etc) doesn't really work. There, the use of two's complement and the fact that every bit pattern is a valid long value together force there to be one more negative value than positive. That leads to all sorts of problems, like Math.abs sometimes being negative. I don't think the same considerations apply to Duration.] Although I gave some use cases for Duration.MAX earlier, I'm not actually aware of any for Duration.MIN. That's partly because Google's internal Durations class defines a public MAX but not a MIN. (Partly out of concern that MIN could be misconstrued to mean the smallest positive Duration, like Double.MIN_VALUE.) So I think it would be an option to define just MAX. On Sun, 12 Oct 2025 at 15:26, Stephen Colebourne <[email protected]> wrote: > Just noting that the conceptual definition of Duration.MAX and MIN > have been in use since Java 8, and I disagree with any change to the > current definition. > > You cannot successfully negate Long.MIN_VALUE, so there is no > requirement that edge cases like this support negation. > > Stephen > > > On Wed, 8 Oct 2025 at 21:29, Pavel Rappo <[email protected]> wrote: > > > > In another thread, there's a question on whether we can define > > Duration.MIN such that it's not the exact minimum, but rather the > > minimum "negatable minimum"? Put differently, can we define > > Duration.MIN as Duration.MAX.negated(), where Duration.MAX is > > Duration.ofSeconds(Long.MAX_VALUE, 999_999_999)? What are the concerns > > with this, if any? > > > > -Pavel > > > > On Wed, Sep 3, 2025 at 1:49 PM Pavel Rappo <[email protected]> > wrote: > > > > > > Couldn't recall or quickly find if this was asked before. > > > > > > I come across this quite often: there doesn’t seem to be a readily > > > available maximum value for java.time.Duration -- a value that > > > represents the longest possible duration. > > > > > > I assume there are plenty of homegrown constants out in the wild > > > addressing this. Don’t get me wrong: it’s not hard to create one. The > > > issue, in my experience, is that it takes time and sometimes > > > experimentation. > > > > > > Unless one reads the Javadoc carefully, it’s not obvious that the > > > maximum duration can be constructed as follows: > > > > > > Duration.of(Long.MAX_VALUE, 999_999_999); > > > > > > Naturally, one might first try using IDE autocomplete. For example, > > > creating a Duration from Long.MAX_VALUE of a large unit -- millennia, > > > centuries, decades, etc. -- only to run into ArithmeticException. Only > > > when reaching seconds does it finally work: > > > > > > Duration.ofSeconds(Long.MAX_VALUE); > > > > > > or > > > > > > Duration.of(Long.MAX_VALUE, ChronoUnit.SECONDS); > > > > > > Of course, there’s no practical difference between > > > Duration.of(Long.MAX_VALUE, 999_999_999) and > > > Duration.ofSeconds(Long.MAX_VALUE). We’re talking about durations on > > > the order of 292 billion years, after all. The exact value isn’t the > > > problem. The problem is that the values are inconsistent, and arriving > > > to them is error-prone. Adding a constant to java.time.Duration would > > > simplify things. > > > > > > -Pavel >
smime.p7s
Description: S/MIME Cryptographic Signature
