On Tue, 23 Nov 2021 23:50:36 GMT, Naoto Sato <na...@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
