Duration.MAX_VALUE

[Pavel Rappo]

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