On Fri, 9 Oct 2026 23:34:25 GMT, Justin Lu <[email protected]> wrote: >> This PR targets a parsing inconsistency for `SimpleDateFormat` when using >> explicit `dstOffset`. >> >> Currently, `SimpleDateFormat` formatting applies the explicit `dstOffset` >> logic when applicable. However, parsing does not consult the explicit >> `dstOffset`, and uses the name in the text to derive whether daylight is in >> effect or not. This can create round trip inconsistencies. >> >> For example, >> >> >> // Historical daylight offset: +00:34:39 >> Date.from(Instant.parse("1916-07-15T00:00:00Z")), >> // Formats to -> 1916-07-15 00:34:39 Greenwich Mean Time >> // ------------- >> // Historical standard offset: −00:25:21 >> Date.from(Instant.parse("1916-01-15T00:00:00Z")), >> // Formats to -> 1916-01-14 23:34:39 Greenwich Mean Time >> >> >> Both formatting calls produce "Greenwich Mean Time" in the text, even though >> the first is in daylight. The second case can round trip because because it >> uses the name to determine standard time. For the first case, the old code >> uses "Greenwich Mean Time" to determine standard time during parsing, even >> though the offset at that date is in daylight time. This produces the >> mismatched `Date`s. This PR updates the parsing path to not set the >> `DST_OFFSET` based on the name, but rather let the `Calendar` naturally >> derive the correct offset from the zone when an explicit `dstOffset` is used. >> >> --------- >> - [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: > > Expand explicit dstOffset support during transition periods
Thanks for the review Naoto! ------------- PR Comment: https://git.openjdk.org/jdk/pull/33235#issuecomment-6150076753
