ADDITIONAL SYSTEM INFORMATION :
OS - affects all
Java - since 8 (introduction of java.time)

A DESCRIPTION OF THE PROBLEM :
Part of java.time is the inclusion of certain "meta" or framework-level types and helpers, for a variety of purposes. Of these, `java.time.temporal.ChronoField` includes a number of standard date-time fields with their expected ranges (encapsulated by a `ValueRange`, and returned by `range()`), like `MONTHS` (with a range of 1-12) and `DAYS_OF_YEAR` (with a range of 1-365/366).

The range of `java.time.temporal.ChronoField.INSTANT_SECONDS`, however, doesn't match the valid, legal, range of `java.time.Instant`'s seconds field.
The range given by `INSTANT_SECONDS` is from `Long.MIN_VALUE` (-9223372036854775808) to `Long.MAX_VALUE` (9223372036854775807)
The range of valid seconds for an `Instant` is only from -31557014167219200 to 31556889864403199

It is not possible to create an `Instant` outside its stated maximum/minimum - doing so throws an exception.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Access the range of `java.time.temporal.ChronoField.INSTANT_SECONDS`

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The `ValueRange` returned from `ChronoField.INSTANT_SECONDS` encodes the same range as is inherent in the type `Instant`.
ACTUAL -
The range is wildly different

---------- BEGIN SOURCE ----------
package example;

import static org.junit.Assert.assertEquals;

import org.junit.Test;

import java.time.temporal.ChronoField;
import java.time.Instant;

/**
 * Unit test for simple App.
 */
public class AppTest {
    /**
     * Rigorous Test :-)
     */
    @Test
    public void shouldMatch() {
        assertEquals(Instant.MIN.getLong(ChronoField.INSTANT_SECONDS),
                ChronoField.INSTANT_SECONDS.range().getMinimum());
        assertEquals(Instant.MAX.getLong(ChronoField.INSTANT_SECONDS),
                ChronoField.INSTANT_SECONDS.range().getMaximum());
    }
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
None - the value is statically provided and cannot be overridden. However, due to how the library is meant to be used this is unlikely to be a large problem.

FREQUENCY : always