8351017: ChronoUnit.MONTHS.between() not giving correct result when date is in February

[naotoj]

Clarifying the explanation for TemporalUnit.between(). There is already an example for the HOURS case where the minutes are not enough to make a full hour. Explaining how smaller units contribute to determining the whole number, along with an explicit MONTHS example, which was the case reported by the bug submitter, will help users.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8351017: ChronoUnit.MONTHS.between() not giving correct result when date is in February (Bug - P4)

Reviewers

• Stephen Colebourne (@jodastephen - Author)
• Roger Riggs (@RogerRiggs - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/23937/head:pull/23937
$ git checkout pull/23937

Update a local copy of the PR:
$ git checkout pull/23937
$ git pull https://git.openjdk.org/jdk.git pull/23937/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 23937

View PR using the GUI difftool:
$ git pr show -t 23937

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/23937.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back naoto! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@naotoj This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8351017: ChronoUnit.MONTHS.between() not giving correct result when date is in February

Reviewed-by: scolebourne, rriggs

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 19 new commits pushed to the master branch:

• 54fe643: 8347433: Deprecate XML interchange in java.management/javax/management/modelmbean/DescriptorSupport for removal
• 155697f: 8349623: [ASAN] Gtest os_linux.glibc_mallinfo_wrapper_vm fails
• 4066f33: 8350565: NMT: remaining memory flag/type to be replaced with memory tag
• 7314efc: 8351377: Fix the ProblemList for com/sun/management/OperatingSystemMXBean cpuLoad tests on AIX
• 7c9a784: 8351223: Update localized resources in keytool and jarsigner
• a23fb0a: 8348110: Update LCMS to 2.17
• 0892913: 8351086: (fc) Make java/nio/channels/FileChannel/BlockDeviceSize.java test manual
• 93f2260: 8351294: (fs) Minor verbiage correction for Files.createTemp{Directory,File}
• 8f8a879: 8350939: Revisit Windows PDH buffer size calculation for OperatingSystemMXBean
• cfab88b: 8351256: Improve printing of runtime call stub names in disassember output
• ... and 9 more: https://git.openjdk.org/jdk/compare/c3b48196af40356a8251b42db13e02ed905c2139...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[openjdk]

@naotoj The following labels will be automatically applied to this pull request:

• core-libs
• i18n

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (126de523)

[RogerRiggs]

A nice, simple and direct clarification. Thanks