<i18n dev> RFR: 8367704: Fix minor documentation issues in java.time.** [v6]

[Pavel Rappo]

On Tue, 16 Sep 2025 17:10:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this documentation-only change, which I believe does **NOT** require CSR.
>> 
>> The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did:
>> 
>> * used a comma separator for some big integer values, to improve readability;
>> * fixed a few typos and grammar.
>> 
>> While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR.
>> 
>> * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive?
>> 
>>         Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2))
>> 
>>   Are there any cases here where that distinction matters?
>> 
>> * In many cases, the following phrase is used throughout documentation:
>> 
>>     > positive or negative
>> 
>>     While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable?
>> 
>> * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   An empty commit to kick GHA

> /csr A CSR is needed due to the changes to the text that imply a change in semantics, for example, changing 'month" to "day". Even if they are viewed as being incorrect, it needs a thorough review.

Thanks for your review, Roger. I'm genuinely confused as to why you think CSR is required here. That month/day is clearly a typo. If it was not, clients would have noticed it long ago.

I could imagine that CSR is required for my change to "positive, negative *or zero* length" duration. If so, let me exclude it from this PR, and instead introduce a new PR where we deal with this and other cases of missed zeros systematically.

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

PR Comment: https://git.openjdk.org/jdk/pull/27296#issuecomment-3300154850