On Tue, 6 Oct 2026 22:09:22 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).

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)

src/java.base/share/classes/java/text/SimpleDateFormat.java line 2548:

> 2546: 
> 2547:     /**
> 2548:      * Obtains the dstOffset for a time zone ID if it exists, otherwise 
> null.

Nit: `ID` is not necessary

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/33235#discussion_r4212930913
PR Review Comment: https://git.openjdk.org/jdk/pull/33235#discussion_r4212933362

Reply via email to