On Tue, 29 Sep 2026 21:33:18 GMT, sbracely <[email protected]> wrote: > > I think the change looks fine and using `getMonthLength` instead of > > `getDayOfYear` does indeed look like the right choice here for the clamping > > logic. > > Just curious if this issue was discovered in an application or through some > > type of deliberate testing. Using a custom Hijrah variant is quite a > > special use case. > > Thanks for the review. > > This wasn't found in a production app. I'm working on a JSR-310 chronology > for the Chinese traditional calendar and chose the same approach as Hijrah: > data-driven month lengths from configuration, rather than computing each date > astronomically at runtime. Published lunisolar tables already disagree with > each other and with historical records, and observatories sometimes revise > previously published future dates, so a fixed config is a better fit.
While reading HijrahDate / HijrahChronology as the model, I noticed #withVariant() used #getDayOfYear() where #resolvePreviousValid() uses #getMonthLength(). I then confirmed it with a custom variant. ------------- PR Comment: https://git.openjdk.org/jdk/pull/33079#issuecomment-5900016942
