On Tue, 9 Apr 2024 08:37:29 GMT, Jaikiran Pai <j...@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. > > Jaikiran Pai has updated the pull request incrementally with one additional > commit since the last revision: > > Naoto's suggestion - use Instant.MIN and Instant.MAX instead of hardcoded > values Thanks, Jai. The code change looks good. (Left a minor nit) src/java.base/share/classes/java/time/temporal/ChronoField.java line 590: > 588: * This is necessary to ensure interoperation between calendars. > 589: * <p> > 590: * Range of {@code InstantSeconds} is between {@link Instant#MIN} > and {@link Instant#MAX} Nit: `InstantSeconds` -> `INSTANT_SECONDS` ------------- PR Review: https://git.openjdk.org/jdk/pull/18674#pullrequestreview-1989561065 PR Review Comment: https://git.openjdk.org/jdk/pull/18674#discussion_r1557961266
