On Thu, 9 Jul 2026 20:54:11 GMT, Naoto Sato <[email protected]> wrote:
>> Hi, >> >> I am not sure that adding a protected method to `java.util.Date` is the >> right approach. Since `Date` is extensible, an existing subclass may already >> declare a `getNormalizedYear()` method. With this change, that method would >> unintentionally override the new method and could change the behavior of >> `toLocalDate()` or `toLocalDateTime()`. >> Instead, I would suggest creating a `GregorianCalendar` initialized from the >> `Date` and deriving the proleptic year from its `ERA` and `YEAR` fields (BC >> = 1 - YEAR). This would avoid adding a new overrideable API to `Date`. > >> @naotoj Understood. I have gone with the `GregorianCalendar` approach as >> recommended. I just want to double check that there aren't any possible >> timezone issues when constructing the calendar? > > I now think this approach would be significantly slower, although it would > still handle the situation correctly, as it creates GregorianCalendar each > time the method is called (time zone is not an issue here). Accessing the > internal calendar via shared secrets might be possible, but I am not sure > that is the right approach either. @naotoj @justin-curtis-lu I just want to say thank you both for all your help with this PR. I was quite nervous about submitting it, however it ended up being a very fun experience. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31808#issuecomment-5047790490
