RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match the range of Instant

[Roger Riggs]

On Mon, 8 Apr 2024 18:00:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8212895?
>> 
>> As noted in that issue, the `ChronoField.INSTANT_SECONDS` currently is initialized to have a minimum and maximum values of `Long.MIN_VALUE` and `LONG.MAX_VALUE` respectively. However, `java.time.Instant` only supports `-31557014167219200L` and `31556889864403199L` as minimum and maximum values for the epoch second.
>> 
>> The commit in this PR updates the `ChronoField.INSTANT_SECONDS`'s value range to match the supported min and max values of `Instant` (as suggested by Stephen in that JBS issue). This commit also introduces a test to verify this change. This new test method as well as existing tests in tier1, tier2 and tier3 continue to pass with this change.
>
> src/java.base/share/classes/java/time/temporal/ChronoField.java line 590:
> 
>> 588:      * This is necessary to ensure interoperation between calendars.
>> 589:      */
>> 590:     // ValueRange matches the min and max epoch second supported by java.time.Instant
> 
> Would we want to include this in the javadoc?

The code should reference the constants in Instant.java (though may need to make them package private.)

The javadoc can/should reference Instant.MIN and Instant.MAX (as the test does).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18674#discussion_r1556243941