Duration.MAX_VALUE

[Éamonn McManus]

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 <scolebourne at joda.org>
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 <pavel.rappo at gmail.com> 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 <pavel.rappo at gmail.com>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251013/e995f124/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5281 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251013/e995f124/smime-0001.p7s>