On Mon, 28 Sep 2026 18:24:45 GMT, Justin Lu <[email protected]> wrote:
>> This PR corrects a case when the explicit DST offset metazone mapping is >> used by `SimpleDateFormat` even when a custom time zone is active. >> >> For example, one can create a custom time zone named "America/Vancouver" >> that has no daylight time. The code before this fix would attempt to match >> the custom zones total offset to the CLDR metazone dstoffset to determine >> daylight time. >> >> Such custom zones should not consult the metazone dstoffset mapping to >> determine their daylight naming. Note that it is fine for custom names to be >> used with a standard zone and still go through the metazone mapping. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Justin Lu has updated the pull request incrementally with one additional > commit since the last revision: > > Reflect review comments (replace isDirty and hasSameRules for equals) + > simplify modified zone test a little Hi! Thank you so much for fixing this so quickly! Much appreciated! 🙌 This looks good to me for JDK-8392995. One performance point to note for JDK-8392996: for a `ZoneInfo` whose ID has an explicit CLDR `dstOffset`, the new canonicality check now also calls `ZoneInfo.getTimeZone(tzid)` on every `z/zzzz` format call. `ZoneInfoFile.getZoneInfo()` clones the cached `ZoneInfo`, so this adds another per-call allocation to the formatting path. JDK-8392996 already covers the repeated `dstOffset` lookup work in `SimpleDateFormat` and `DateTimeFormatter`. I think it should also cover avoiding this new canonical-zone lookup and clone, so the eventual fix should address all affected formatting paths. ------------- PR Comment: https://git.openjdk.org/jdk/pull/33074#issuecomment-5900880917
