<i18n dev> RFR: 8177819: DateTimeFormatterBuilder zone parsing should recognise DST [v2]

[Joe Wang]

On Tue, 23 Nov 2021 23:50:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This fix intends to honor the type (std/dst/generic) of parsed zone name for selecting the offset at the overlap. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined wording

For the compatibility assessment, it looks like an incompatible change since apps that expect DST will get a different offset at the overlap. The risk is low, perhaps because of the rare use case? That additional explanation might be helpful.

src/java.base/share/classes/java/time/format/DateTimeFormatter.java line 509:

> 507:  * parsed from the zone name that does not imply daylight saving time, then
> 508:  * {@link ChronoZonedDateTime#withLaterOffsetAtOverlap()} is issued
> 509:  * to use the standard offset at the overlap, before forming the instant.

Is the standard offset the subject instead of the withLaterOffsetAtOverlap method? Calling the method seems to be an impl detail to me. We might rephrase the sentence to sth. like:
If the {@code ZoneId} parsed does not indicate daylight saving time, the standard offset will be used at the local time-line overlap as specified in the {@link ChronoZonedDateTime#withLaterOffsetAtOverlap()} method to form the instant.

src/java.base/share/classes/java/time/format/Parsed.java line 139:

> 137:      * The parsed zone name type.
> 138:      */
> 139:     int zoneNameType = -1;

Could be an Enum if that helps with readability.

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

PR: https://git.openjdk.java.net/jdk/pull/6527