On Fri, 9 Oct 2026 23:27:21 GMT, Justin Lu <[email protected]> wrote: >> src/java.base/share/classes/java/text/SimpleDateFormat.java line 1844: >> >>> 1842: if (!(useSameName || (nameIndex >= 3 && dstAmount == >>> 0))) { >>> 1843: >>> calb.clear(Calendar.ZONE_OFFSET).set(Calendar.DST_OFFSET, dstAmount); >>> 1844: } >> >> I think we still need to adjust the offset even if `explicitDstOffset` is in >> effect. Otherwise, round-tripping would fail for instants at the dst/std (or >> vice versa) transition period, e.g., `2026-10-25T01:30:00` (Dublin local >> time) > > That's a good point. Pushed > https://github.com/openjdk/jdk/pull/33235/commits/6b8ff0c32efd8cfa9b9f19edfc4d1a2a69e4862b. > > From what I can tell, there isn't a way for us to accurately decide what to > do during `PATTERN_ZONE_NAME` processing, so we have to handle such cases > later. > > Once the final date is resolved, if it is during a transition period, we can > use the matched name as the tiebreaker to decide the correct offset. This > added overhead should only apply to an explicit `dstOffset` zone, which the > vast majority of cases are not. I opted to use an `int[] matchedName` array > to carry the matched name back out, similar to what is done with `boolean[] > ambiguousYear`. > > I think some trickiness is making sure that the behavior lines up with > standard non explicit `dstOffset` parsing. i.e. in terms of identical names, > subsequent 'z/x' time zone patterns, centuries. > > It is unfortunate that this regression is quite specific, (explicit > `dstOffset` plus historical zone mismatch) and probably does not carry its > weight in terms of the code required for it, but it is a regression > nonetheless.
Agreed. I guess we have no choice but to rely on the name lookup for those transition periods, which can sometimes be fragile. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/33235#discussion_r4251698167
