On Fri, 17 Jul 2026 11:45:35 GMT, Sholto <[email protected]> wrote: >> src/java.sql/share/classes/java/sql/Date.java line 324: >> >>> 322: // 0002-01-01 are AD, we can use a much faster local date >>> derivation >>> 323: // for these dates. >>> 324: if (getTime() >= TWO_AD_AT_UTC_EPOCH_MILLIS) { >> >> We can pull out the shared logic here and in `Timestamp` and create a static >> package-private helper in `java.sql.Date`. >> >> Something like >> >> >> static int toProlepticYear(long millis, int year) { >> if slow path >> set calendar using setTimeInMillis >> if calendar is in BC >> adjust year >> return year; >> >> } >> >> >> The helper can call `GregorianCalendar.setTimeInMillis(...)` instead of >> `GregorianCalendar.setTime(...)`. That lets us pass its millisecond value >> via `getTime()` rather than having to pass `this` as a `java.util.Date` to >> the helper method. I also think within the helper, you can inverse the >> `getTime() >= TWO_AD_AT_UTC_EPOCH_MILLIS` conditional to simplify the logic >> some more. >> >> After that, `toLocalDate` need only look something like, >> >> >> return LocalDate.of( >> toProlepticYear(getTime(), getYear() + 1900), >> getMonth() + 1, >> getDate()); > > Yup great idea. I have updated this as suggested.
Did we want unit tests specifically for the new `toProlepticYear` method? Or are we happy with the coverage provided by the existing `dateTimesAroundBcCheckThreshold` checks? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31808#discussion_r3602880568
