Summary

Parsing dst aware zone name should choose the zone offset correctly for date/time at the dst->std overlap.

Problem

When parsing a date/time string at dst->std overlap, the current implementation always chooses the dst offset, even if the source string contains non-DST zone name.

Solution

If the source string contains non-DST zone name, and without any explict offset (such as "+0100"), parsing should choose standard offset, instead of daylight saving offset.

Specification

In java.time.format.DateTimeFormatter's class description, change the number 10 item in the numbered list at "Resolving" section as follows:

   * the field {@link ChronoField#INSTANT_SECONDS} is created.
   * If an offset was parsed then the offset will be combined with the
   * {@code LocalDateTime} to form the instant, with any zone ignored.
   * If a {@code ZoneId} was parsed without an offset then the zone will be
   * combined with the {@code LocalDateTime} to form the instant using the rules
-  * of {@link ChronoLocalDateTime#atZone(ZoneId)}.
+  * of {@link ChronoLocalDateTime#atZone(ZoneId)}. If the {@code ZoneId} was
+  * parsed from a zone name that indicates whether daylight saving time is in
+  * operation or not, then that fact will be used to select the correct offset
+  * at the local time-line overlap.
   * </ol>
   *
   * @implSpec
   * This class is immutable and thread-safe.
   *

Additionally, fix the following typos: