On Tue, 22 Sep 2026 19:09:02 GMT, sbracely <[email protected]> wrote:
>> createEpochMonths() used minYear in the invalid-month-length message.
>> Use the loop variable year.
>>
>> HijrahConfigTest copies an invalid custom config and checks
>> the DateTimeException cause message names 1448.
>>
>> ---------
>> - [x] I confirm that I make this contribution in accordance with the
>> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai).
>
> sbracely has refreshed the contents of this pull request, and previous
> commits have been removed. The incremental views will show differences
> compared to the previous content of the PR. The pull request contains one new
> commit since the last revision:
>
> 8392848: HijrahChronology.createEpochMonths reports minYear instead of the
> invalid year
src/java.base/share/classes/java/time/chrono/HijrahChronology.java line 947:
> 945: epochMonths[epochMonth++] = epochDay;
> 946:
> 947: if (length < 29 || length > 32) {
Looking at the upper bound length, it is oddly 32. And that upper bound is
indeed supported by the wording in the implementation note for the custom
variant loading
> The month lengths must be between 29-32 inclusive.
However, the upper bound of a regular Hijrah calendar is 30 days. As supported
by the standard specification,
> The length of each month is 29 or 30 days
@naotoj do you know if there is some historical basis to this? From what I can
tell, it seems like an oversight.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/33015#discussion_r4076495387
