On Wed, 7 Oct 2026 23:06:32 GMT, Naoto Sato <[email protected]> wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Expand explicit dstOffset support during transition periods
>
> 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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/33235#discussion_r4235372415
