8026516: javadoc errors in java.time
Summary: Corrected links to TemporalQuery and TemporalField.resolve
Reviewed-by: mduigou, darcy, lancea
--- a/jdk/src/share/classes/java/time/Instant.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/Instant.java Thu Oct 17 10:37:23 2013 -0400
@@ -156,14 +156,14 @@
* internationally-agreed time scale is modified or replaced, a new
* segment of the Java Time-Scale must be defined for it. Each segment
* must meet these requirements:
- * <p><ul>
+ * <ul>
* <li>the Java Time-Scale shall closely match the underlying international
* civil time scale;</li>
* <li>the Java Time-Scale shall exactly match the international civil
* time scale at noon each day;</li>
* <li>the Java Time-Scale shall have a precisely-defined relationship to
* the international civil time scale.</li>
- * </ul><p>
+ * </ul>
* There are currently, as of 2013, two segments in the Java time-scale.
* <p>
* For the segment from 1972-11-03 (exact boundary discussed below) until
--- a/jdk/src/share/classes/java/time/LocalDateTime.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/LocalDateTime.java Thu Oct 17 10:37:23 2013 -0400
@@ -1941,13 +1941,13 @@
* Outputs this date-time as a {@code String}, such as {@code 2007-12-03T10:15:30}.
* <p>
* The output will be one of the following ISO-8601 formats:
- * <p><ul>
+ * <ul>
* <li>{@code uuuu-MM-dd'T'HH:mm}</li>
* <li>{@code uuuu-MM-dd'T'HH:mm:ss}</li>
* <li>{@code uuuu-MM-dd'T'HH:mm:ss.SSS}</li>
* <li>{@code uuuu-MM-dd'T'HH:mm:ss.SSSSSS}</li>
* <li>{@code uuuu-MM-dd'T'HH:mm:ss.SSSSSSSSS}</li>
- * </ul><p>
+ * </ul>
* The format used will be the shortest that outputs the full value of
* the time where the omitted parts are implied to be zero.
*
--- a/jdk/src/share/classes/java/time/LocalTime.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/LocalTime.java Thu Oct 17 10:37:23 2013 -0400
@@ -1554,13 +1554,13 @@
* Outputs this time as a {@code String}, such as {@code 10:15}.
* <p>
* The output will be one of the following ISO-8601 formats:
- * <p><ul>
+ * <ul>
* <li>{@code HH:mm}</li>
* <li>{@code HH:mm:ss}</li>
* <li>{@code HH:mm:ss.SSS}</li>
* <li>{@code HH:mm:ss.SSSSSS}</li>
* <li>{@code HH:mm:ss.SSSSSSSSS}</li>
- * </ul><p>
+ * </ul>
* The format used will be the shortest that outputs the full value of
* the time where the omitted parts are implied to be zero.
*
--- a/jdk/src/share/classes/java/time/OffsetDateTime.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/OffsetDateTime.java Thu Oct 17 10:37:23 2013 -0400
@@ -1880,13 +1880,13 @@
* Outputs this date-time as a {@code String}, such as {@code 2007-12-03T10:15:30+01:00}.
* <p>
* The output will be one of the following ISO-8601 formats:
- * <p><ul>
+ * <ul>
* <li>{@code uuuu-MM-dd'T'HH:mmXXXXX}</li>
* <li>{@code uuuu-MM-dd'T'HH:mm:ssXXXXX}</li>
* <li>{@code uuuu-MM-dd'T'HH:mm:ss.SSSXXXXX}</li>
* <li>{@code uuuu-MM-dd'T'HH:mm:ss.SSSSSSXXXXX}</li>
* <li>{@code uuuu-MM-dd'T'HH:mm:ss.SSSSSSSSSXXXXX}</li>
- * </ul><p>
+ * </ul>
* The format used will be the shortest that outputs the full value of
* the time where the omitted parts are implied to be zero.
*
--- a/jdk/src/share/classes/java/time/OffsetTime.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/OffsetTime.java Thu Oct 17 10:37:23 2013 -0400
@@ -1351,13 +1351,13 @@
* Outputs this time as a {@code String}, such as {@code 10:15:30+01:00}.
* <p>
* The output will be one of the following ISO-8601 formats:
- * <p><ul>
+ * <ul>
* <li>{@code HH:mmXXXXX}</li>
* <li>{@code HH:mm:ssXXXXX}</li>
* <li>{@code HH:mm:ss.SSSXXXXX}</li>
* <li>{@code HH:mm:ss.SSSSSSXXXXX}</li>
* <li>{@code HH:mm:ss.SSSSSSSSSXXXXX}</li>
- * </ul><p>
+ * </ul>
* The format used will be the shortest that outputs the full value of
* the time where the omitted parts are implied to be zero.
*
--- a/jdk/src/share/classes/java/time/ZoneId.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/ZoneId.java Thu Oct 17 10:37:23 2013 -0400
@@ -89,12 +89,12 @@
* A {@code ZoneId} is used to identify the rules used to convert between
* an {@link Instant} and a {@link LocalDateTime}.
* There are two distinct types of ID:
- * <p><ul>
+ * <ul>
* <li>Fixed offsets - a fully resolved offset from UTC/Greenwich, that uses
* the same offset for all local date-times
* <li>Geographical regions - an area where a specific set of rules for finding
* the offset from UTC/Greenwich apply
- * </ul><p>
+ * </ul>
* Most fixed offsets are represented by {@link ZoneOffset}.
* Calling {@link #normalized()} on any {@code ZoneId} will ensure that a
* fixed offset ID will be represented as a {@code ZoneOffset}.
@@ -180,7 +180,7 @@
* This is in line with versions of TZDB before 2005r.
* <p>
* This maps as follows:
- * <p><ul>
+ * <ul>
* <li>EST - America/New_York</li>
* <li>MST - America/Denver</li>
* <li>HST - Pacific/Honolulu</li>
@@ -209,7 +209,7 @@
* <li>PST - America/Los_Angeles</li>
* <li>SST - Pacific/Guadalcanal</li>
* <li>VST - Asia/Ho_Chi_Minh</li>
- * </ul><p>
+ * </ul>
* The map is unmodifiable.
*/
public static final Map<String, String> OLD_SHORT_IDS;
@@ -225,7 +225,7 @@
* This is in line with TZDB 2005r and later.
* <p>
* This maps as follows:
- * <p><ul>
+ * <ul>
* <li>EST - -05:00</li>
* <li>HST - -10:00</li>
* <li>MST - -07:00</li>
@@ -254,7 +254,7 @@
* <li>PST - America/Los_Angeles</li>
* <li>SST - Pacific/Guadalcanal</li>
* <li>VST - Asia/Ho_Chi_Minh</li>
- * </ul><p>
+ * </ul>
* The map is unmodifiable.
*/
public static final Map<String, String> SHORT_IDS;
--- a/jdk/src/share/classes/java/time/ZoneOffset.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/ZoneOffset.java Thu Oct 17 10:37:23 2013 -0400
@@ -166,7 +166,7 @@
* This method parses the string ID of a {@code ZoneOffset} to
* return an instance. The parsing accepts all the formats generated by
* {@link #getId()}, plus some additional formats:
- * <p><ul>
+ * <ul>
* <li>{@code Z} - for UTC
* <li>{@code +h}
* <li>{@code +hh}
@@ -178,7 +178,7 @@
* <li>{@code -hh:mm:ss}
* <li>{@code +hhmmss}
* <li>{@code -hhmmss}
- * </ul><p>
+ * </ul>
* Note that ± means either the plus or minus symbol.
* <p>
* The ID of the returned offset will be normalized to one of the formats
@@ -471,11 +471,11 @@
* <p>
* The ID is minor variation to the standard ISO-8601 formatted string
* for the offset. There are three formats:
- * <p><ul>
+ * <ul>
* <li>{@code Z} - for UTC (ISO-8601)
* <li>{@code +hh:mm} or {@code -hh:mm} - if the seconds are zero (ISO-8601)
* <li>{@code +hh:mm:ss} or {@code -hh:mm:ss} - if the seconds are non-zero (not ISO-8601)
- * </ul><p>
+ * </ul>
*
* @return the zone offset ID, not null
*/
--- a/jdk/src/share/classes/java/time/ZonedDateTime.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/ZonedDateTime.java Thu Oct 17 10:37:23 2013 -0400
@@ -111,7 +111,7 @@
* Obtaining the offset for an instant is simple, as there is exactly one valid
* offset for each instant. By contrast, obtaining the offset for a local date-time
* is not straightforward. There are three cases:
- * <p><ul>
+ * <ul>
* <li>Normal, with one valid offset. For the vast majority of the year, the normal
* case applies, where there is a single valid offset for the local date-time.</li>
* <li>Gap, with zero valid offsets. This is when clocks jump forward typically
@@ -120,7 +120,7 @@
* <li>Overlap, with two valid offsets. This is when clocks are set back typically
* due to the autumn daylight savings change from "summer" to "winter".
* In an overlap there are local date-time values with two valid offsets.</li>
- * </ul><p>
+ * </ul>
* <p>
* Any method that converts directly or implicitly from a local date-time to an
* instant by obtaining the offset has the potential to be complicated.
@@ -1699,12 +1699,12 @@
* <p>
* For example, consider a time-zone where the spring DST cutover means that the
* local times 01:00 to 01:59 occur twice changing from offset +02:00 to +01:00.
- * <p><ul>
+ * <ul>
* <li>Adding one hour to 00:30+02:00 will result in 01:30+02:00
* <li>Adding one hour to 01:30+02:00 will result in 01:30+01:00
* <li>Adding one hour to 01:30+01:00 will result in 02:30+01:00
* <li>Adding three hours to 00:30+02:00 will result in 02:30+01:00
- * </ul><p>
+ * </ul>
* <p>
* This instance is immutable and unaffected by this method call.
*
@@ -1940,12 +1940,12 @@
* <p>
* For example, consider a time-zone where the spring DST cutover means that the
* local times 01:00 to 01:59 occur twice changing from offset +02:00 to +01:00.
- * <p><ul>
+ * <ul>
* <li>Subtracting one hour from 02:30+01:00 will result in 01:30+02:00
* <li>Subtracting one hour from 01:30+01:00 will result in 01:30+02:00
* <li>Subtracting one hour from 01:30+02:00 will result in 00:30+01:00
* <li>Subtracting three hours from 02:30+01:00 will result in 00:30+02:00
- * </ul><p>
+ * </ul>
* <p>
* This instance is immutable and unaffected by this method call.
*
--- a/jdk/src/share/classes/java/time/chrono/ChronoLocalDate.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/chrono/ChronoLocalDate.java Thu Oct 17 10:37:23 2013 -0400
@@ -195,13 +195,13 @@
*
* <h3>Using LocalDate instead</h3>
* The primary alternative to using this interface throughout your application is as follows.
- * <p><ul>
+ * <ul>
* <li>Declare all method signatures referring to dates in terms of {@code LocalDate}.
* <li>Either store the chronology (calendar system) in the user profile or lookup
* the chronology from the user locale
* <li>Convert the ISO {@code LocalDate} to and from the user's preferred calendar system during
* printing and parsing
- * </ul><p>
+ * </ul>
* This approach treats the problem of globalized calendar systems as a localization issue
* and confines it to the UI layer. This approach is in keeping with other localization
* issues in the java platform.
@@ -222,13 +222,13 @@
* For example, an application may need to calculate the next Islamic or Hebrew holiday
* which may require manipulating the date.
* This kind of use case can be handled as follows:
- * <p><ul>
+ * <ul>
* <li>start from the ISO {@code LocalDate} being passed to the method
* <li>convert the date to the alternate calendar system, which for this use case is known
* rather than arbitrary
* <li>perform the calculation
* <li>convert back to {@code LocalDate}
- * </ul><p>
+ * </ul>
* Developers writing low-level frameworks or libraries should also avoid this interface.
* Instead, one of the two general purpose access interfaces should be used.
* Use {@link TemporalAccessor} if read-only access is required, or use {@link Temporal}
--- a/jdk/src/share/classes/java/time/chrono/Chronology.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/chrono/Chronology.java Thu Oct 17 10:37:23 2013 -0400
@@ -117,7 +117,7 @@
* <p>
* The {@code Chronology} instance provides a set of methods to create {@code ChronoLocalDate} instances.
* The date classes are used to manipulate specific dates.
- * <p><ul>
+ * <ul>
* <li> {@link #dateNow() dateNow()}
* <li> {@link #dateNow(Clock) dateNow(clock)}
* <li> {@link #dateNow(ZoneId) dateNow(zone)}
@@ -126,7 +126,7 @@
* <li> {@link #dateYearDay(int, int) dateYearDay(yearProleptic, dayOfYear)}
* <li> {@link #dateYearDay(Era, int, int) dateYearDay(era, yearOfEra, dayOfYear)}
* <li> {@link #date(TemporalAccessor) date(TemporalAccessor)}
- * </ul><p>
+ * </ul>
*
* <h3 id="addcalendars">Adding New Calendars</h3>
* The set of available chronologies can be extended by applications.
@@ -163,10 +163,10 @@
* A {@code TemporalAccessor} represents an arbitrary set of date and time information,
* which this factory converts to an instance of {@code Chronology}.
* <p>
- * The conversion will obtain the chronology using {@link TemporalQueries.chronology()}.
+ * The conversion will obtain the chronology using {@link TemporalQueries#chronology()}.
* If the specified temporal object does not have a chronology, {@link IsoChronology} is returned.
* <p>
- * This method matches the signature of the functional interface {@link TemporalQueries.
+ * This method matches the signature of the functional interface {@link TemporalQuery}
* allowing it to be used in queries via method reference, {@code Chronology::from}.
*
* @param temporal the temporal to convert, not null
@@ -435,7 +435,7 @@
* The conversion typically uses the {@link ChronoField#EPOCH_DAY EPOCH_DAY}
* field, which is standardized across calendar systems.
* <p>
- * This method matches the signature of the functional interface {@link TemporalQueries.
+ * This method matches the signature of the functional interface {@link TemporalQuery}
* allowing it to be used as a query via method reference, {@code aChronology::date}.
*
* @param temporal the temporal object to convert, not null
@@ -458,7 +458,7 @@
* those fields that are equivalent to the relevant objects.
* The result uses this chronology.
* <p>
- * This method matches the signature of the functional interface {@link TemporalQueries.
+ * This method matches the signature of the functional interface {@link TemporalQuery}
* allowing it to be used as a query via method reference, {@code aChronology::localDateTime}.
*
* @param temporal the temporal object to convert, not null
@@ -490,7 +490,7 @@
* those fields that are equivalent to the relevant objects.
* The result uses this chronology.
* <p>
- * This method matches the signature of the functional interface {@link TemporalQueries.
+ * This method matches the signature of the functional interface {@link TemporalQuery}
* allowing it to be used as a query via method reference, {@code aChronology::zonedDateTime}.
*
* @param temporal the temporal object to convert, not null
@@ -534,10 +534,10 @@
* <p>
* A leap-year is a year of a longer length than normal.
* The exact meaning is determined by the chronology according to the following constraints.
- * <p><ul>
+ * <ul>
* <li>a leap-year must imply a year-length longer than a non leap-year.
* <li>a chronology that does not support the concept of a year must return false.
- * </ul><p>
+ * </ul>
*
* @param prolepticYear the proleptic-year to check, not validated for range
* @return true if the year is a leap year
--- a/jdk/src/share/classes/java/time/chrono/Era.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/chrono/Era.java Thu Oct 17 10:37:23 2013 -0400
@@ -111,11 +111,11 @@
* All fields, including eras, have an associated numeric value.
* The meaning of the numeric value for era is determined by the chronology
* according to these principles:
- * <p><ul>
+ * <ul>
* <li>The era in use at the epoch 1970-01-01 (ISO) has the value 1.
* <li>Later eras have sequentially higher values.
* <li>Earlier eras have sequentially lower values, which may be negative.
- * </ul><p>
+ * </ul>
*
* @return the numeric era value
*/
--- a/jdk/src/share/classes/java/time/chrono/IsoChronology.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/chrono/IsoChronology.java Thu Oct 17 10:37:23 2013 -0400
@@ -100,7 +100,7 @@
* <i>de facto</i> world calendar.
* <p>
* The fields are defined as follows:
- * <p><ul>
+ * <ul>
* <li>era - There are two eras, 'Current Era' (CE) and 'Before Current Era' (BCE).
* <li>year-of-era - The year-of-era is the same as the proleptic-year for the current CE era.
* For the BCE era before the ISO epoch the year increases from 1 upwards as time goes backwards.
@@ -113,7 +113,7 @@
* <li>day-of-year - There are 365 days in a standard ISO year and 366 in a leap year.
* The days are numbered from 1 to 365 or 1 to 366.
* <li>leap-year - Leap years occur every 4 years, except where the year is divisble by 100 and not divisble by 400.
- * </ul><p>
+ * </ul>
*
* @implSpec
* This class is immutable and thread-safe.
--- a/jdk/src/share/classes/java/time/chrono/IsoEra.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/chrono/IsoEra.java Thu Oct 17 10:37:23 2013 -0400
@@ -69,7 +69,7 @@
* The ISO-8601 standard does not define eras.
* A definition has therefore been created with two eras - 'Current era' (CE) for
* years on or after 0001-01-01 (ISO), and 'Before current era' (BCE) for years before that.
- * <p>
+ *
* <table summary="ISO years and eras" cellpadding="2" cellspacing="3" border="0" >
* <thead>
* <tr class="tableSubHeadingColor">
--- a/jdk/src/share/classes/java/time/chrono/MinguoChronology.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/chrono/MinguoChronology.java Thu Oct 17 10:37:23 2013 -0400
@@ -85,7 +85,7 @@
* Dates are aligned such that {@code 0001-01-01 (Minguo)} is {@code 1912-01-01 (ISO)}.
* <p>
* The fields are defined as follows:
- * <p><ul>
+ * <ul>
* <li>era - There are two eras, the current 'Republic' (ERA_ROC) and the previous era (ERA_BEFORE_ROC).
* <li>year-of-era - The year-of-era for the current era increases uniformly from the epoch at year one.
* For the previous era the year increases from one as time goes backwards.
@@ -98,7 +98,7 @@
* <li>day-of-year - The Minguo day-of-year exactly matches ISO.
* <li>leap-year - The Minguo leap-year pattern exactly matches ISO, such that the two calendars
* are never out of step.
- * </ul><p>
+ * </ul>
*
* @implSpec
* This class is immutable and thread-safe.
--- a/jdk/src/share/classes/java/time/chrono/MinguoEra.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/chrono/MinguoEra.java Thu Oct 17 10:37:23 2013 -0400
@@ -70,7 +70,7 @@
* The current era, for years from 1 onwards, is known as the 'Republic of China' era.
* All previous years, zero or earlier in the proleptic count or one and greater
* in the year-of-era count, are part of the 'Before Republic of China' era.
- * <p>
+ *
* <table summary="Minguo years and eras" cellpadding="2" cellspacing="3" border="0" >
* <thead>
* <tr class="tableSubHeadingColor">
--- a/jdk/src/share/classes/java/time/chrono/ThaiBuddhistChronology.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/chrono/ThaiBuddhistChronology.java Thu Oct 17 10:37:23 2013 -0400
@@ -86,7 +86,7 @@
* Dates are aligned such that {@code 2484-01-01 (Buddhist)} is {@code 1941-01-01 (ISO)}.
* <p>
* The fields are defined as follows:
- * <p><ul>
+ * <ul>
* <li>era - There are two eras, the current 'Buddhist' (ERA_BE) and the previous era (ERA_BEFORE_BE).
* <li>year-of-era - The year-of-era for the current era increases uniformly from the epoch at year one.
* For the previous era the year increases from one as time goes backwards.
@@ -99,7 +99,7 @@
* <li>day-of-year - The ThaiBuddhist day-of-year exactly matches ISO.
* <li>leap-year - The ThaiBuddhist leap-year pattern exactly matches ISO, such that the two calendars
* are never out of step.
- * </ul><p>
+ * </ul>
*
* @implSpec
* This class is immutable and thread-safe.
--- a/jdk/src/share/classes/java/time/chrono/ThaiBuddhistEra.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/chrono/ThaiBuddhistEra.java Thu Oct 17 10:37:23 2013 -0400
@@ -70,7 +70,7 @@
* The current era, for years from 1 onwards, is known as the 'Buddhist' era.
* All previous years, zero or earlier in the proleptic count or one and greater
* in the year-of-era count, are part of the 'Before Buddhist' era.
- * <p>
+ *
* <table summary="Buddhist years and eras" cellpadding="2" cellspacing="3" border="0" >
* <thead>
* <tr class="tableSubHeadingColor">
--- a/jdk/src/share/classes/java/time/format/DateTimeFormatter.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/format/DateTimeFormatter.java Thu Oct 17 10:37:23 2013 -0400
@@ -146,7 +146,7 @@
* Some applications may need to use the older {@link Format java.text.Format}
* class for formatting. The {@link #toFormat()} method returns an
* implementation of {@code java.text.Format}.
- * <p>
+ *
* <h3 id="predefined">Predefined Formatters</h3>
* <table summary="Predefined Formatters" cellpadding="2" cellspacing="3" border="0" >
* <thead>
@@ -460,7 +460,7 @@
* <li>The {@code ChronoField} time fields are resolved.
* This is documented on {@link ChronoField} and is the same for all chronologies.
* <li>Any fields that are not {@code ChronoField} are processed.
- * This is achieved using {@link TemporalField#resolve(Map, Chronology, ZoneId, ResolverStyle)}.
+ * This is achieved using {@link TemporalField#resolve(Map, TemporalAccessor, ResolverStyle)}.
* Documentation about field resolution is located in the implementation
* of {@code TemporalField}.
* <li>The {@code ChronoField} date and time fields are re-resolved.
@@ -684,7 +684,7 @@
* This returns an immutable formatter capable of formatting and parsing
* the ISO-8601 extended local date format.
* The format consists of:
- * <p><ul>
+ * <ul>
* <li>Four digits or more for the {@link ChronoField#YEAR year}.
* Years in the range 0000 to 9999 will be pre-padded by zero to ensure four digits.
* Years outside that range will have a prefixed positive or negative symbol.
@@ -719,7 +719,7 @@
* This returns an immutable formatter capable of formatting and parsing
* the ISO-8601 extended offset date format.
* The format consists of:
- * <p><ul>
+ * <ul>
* <li>The {@link #ISO_LOCAL_DATE}
* <li>The {@link ZoneOffset#getId() offset ID}. If the offset has seconds then
* they will be handled even though this is not part of the ISO-8601 standard.
@@ -747,7 +747,7 @@
* This returns an immutable formatter capable of formatting and parsing
* the ISO-8601 extended date format.
* The format consists of:
- * <p><ul>
+ * <ul>
* <li>The {@link #ISO_LOCAL_DATE}
* <li>If the offset is not available then the format is complete.
* <li>The {@link ZoneOffset#getId() offset ID}. If the offset has seconds then
@@ -780,7 +780,7 @@
* This returns an immutable formatter capable of formatting and parsing
* the ISO-8601 extended local time format.
* The format consists of:
- * <p><ul>
+ * <ul>
* <li>Two digits for the {@link ChronoField#HOUR_OF_DAY hour-of-day}.
* This is pre-padded by zero to ensure two digits.
* <li>A colon
@@ -821,7 +821,7 @@
* This returns an immutable formatter capable of formatting and parsing
* the ISO-8601 extended offset time format.
* The format consists of:
- * <p><ul>
+ * <ul>
* <li>The {@link #ISO_LOCAL_TIME}
* <li>The {@link ZoneOffset#getId() offset ID}. If the offset has seconds then
* they will be handled even though this is not part of the ISO-8601 standard.
@@ -848,7 +848,7 @@
* This returns an immutable formatter capable of formatting and parsing
* the ISO-8601 extended offset time format.
* The format consists of:
- * <p><ul>
+ * <ul>
* <li>The {@link #ISO_LOCAL_TIME}
* <li>If the offset is not available then the format is complete.
* <li>The {@link ZoneOffset#getId() offset ID}. If the offset has seconds then
@@ -880,7 +880,7 @@
* This returns an immutable formatter capable of formatting and parsing
* the ISO-8601 extended offset date-time format.
* The format consists of:
- * <p><ul>
+ * <ul>
* <li>The {@link #ISO_LOCAL_DATE}
* <li>The letter 'T'. Parsing is case insensitive.
* <li>The {@link #ISO_LOCAL_TIME}
@@ -908,7 +908,7 @@
* This returns an immutable formatter capable of formatting and parsing
* the ISO-8601 extended offset date-time format.
* The format consists of:
- * <p><ul>
+ * <ul>
* <li>The {@link #ISO_LOCAL_DATE_TIME}
* <li>The {@link ZoneOffset#getId() offset ID}. If the offset has seconds then
* they will be handled even though this is not part of the ISO-8601 standard.
@@ -938,7 +938,7 @@
* to add the time-zone.
* The section in square brackets is not part of the ISO-8601 standard.
* The format consists of:
- * <p><ul>
+ * <ul>
* <li>The {@link #ISO_OFFSET_DATE_TIME}
* <li>If the zone ID is not available or is a {@code ZoneOffset} then the format is complete.
* <li>An open square bracket '['.
@@ -973,7 +973,7 @@
* the ISO-8601 extended local or offset date-time format, as well as the
* extended non-ISO form specifying the time-zone.
* The format consists of:
- * <p><ul>
+ * <ul>
* <li>The {@link #ISO_LOCAL_DATE_TIME}
* <li>If the offset is not available to format or parse then the format is complete.
* <li>The {@link ZoneOffset#getId() offset ID}. If the offset has seconds then
@@ -1014,7 +1014,7 @@
* This returns an immutable formatter capable of formatting and parsing
* the ISO-8601 extended ordinal date format.
* The format consists of:
- * <p><ul>
+ * <ul>
* <li>Four digits or more for the {@link ChronoField#YEAR year}.
* Years in the range 0000 to 9999 will be pre-padded by zero to ensure four digits.
* Years outside that range will have a prefixed positive or negative symbol.
@@ -1054,7 +1054,7 @@
* This returns an immutable formatter capable of formatting and parsing
* the ISO-8601 extended week-based date format.
* The format consists of:
- * <p><ul>
+ * <ul>
* <li>Four digits or more for the {@link IsoFields#WEEK_BASED_YEAR week-based-year}.
* Years in the range 0000 to 9999 will be pre-padded by zero to ensure four digits.
* Years outside that range will have a prefixed positive or negative symbol.
@@ -1114,7 +1114,7 @@
* a suitable conversion using {@code ZoneOffset.UTC}.
* <p>
* The format consists of:
- * <p><ul>
+ * <ul>
* <li>The {@link #ISO_OFFSET_DATE_TIME} where the instant is converted from
* {@link ChronoField#INSTANT_SECONDS} and {@link ChronoField#NANO_OF_SECOND}
* using the {@code UTC} offset. Parsing is case insensitive.
@@ -1139,7 +1139,7 @@
* This returns an immutable formatter capable of formatting and parsing
* the ISO-8601 basic local date format.
* The format consists of:
- * <p><ul>
+ * <ul>
* <li>Four digits for the {@link ChronoField#YEAR year}.
* Only years in the range 0000 to 9999 are supported.
* <li>Two digits for the {@link ChronoField#MONTH_OF_YEAR month-of-year}.
@@ -1183,7 +1183,7 @@
* names, only 'GMT' and offset amounts.
* <p>
* The format consists of:
- * <p><ul>
+ * <ul>
* <li>If the day-of-week is not available to format or parse then jump to day-of-month.
* <li>Three letter {@link ChronoField#DAY_OF_WEEK day-of-week} in English.
* <li>A comma
@@ -1274,11 +1274,11 @@
* a non-null period, with a zero period returned instead of null.
* <p>
* There are two situations where this query may return a non-zero period.
- * <p><ul>
+ * <ul>
* <li>If the {@code ResolverStyle} is {@code LENIENT} and a time is parsed
* without a date, then the complete result of the parse consists of a
* {@code LocalTime} and an excess {@code Period} in days.
- * <p>
+ *
* <li>If the {@code ResolverStyle} is {@code SMART} and a time is parsed
* without a date where the time is 24:00:00, then the complete result of
* the parse consists of a {@code LocalTime} of 00:00:00 and an excess
--- a/jdk/src/share/classes/java/time/format/DateTimeFormatterBuilder.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/format/DateTimeFormatterBuilder.java Thu Oct 17 10:37:23 2013 -0400
@@ -125,7 +125,7 @@
* All date-time formatters are created ultimately using this builder.
* <p>
* The basic elements of date-time can all be added:
- * <p><ul>
+ * <ul>
* <li>Value - a numeric value</li>
* <li>Fraction - a fractional value including the decimal place. Always use this when
* outputting fractions to ensure that the fraction is parsed correctly</li>
@@ -138,7 +138,7 @@
* <li>Literal - a text literal</li>
* <li>Nested and Optional - formats can be nested or made optional</li>
* <li>Other - the printer and parser interfaces can be used to add user supplied formatting</li>
- * </ul><p>
+ * </ul>
* In addition, any of the elements may be decorated by padding, either with spaces or any other character.
* <p>
* Finally, a shorthand pattern, mostly compatible with {@code java.text.SimpleDateFormat SimpleDateFormat}
@@ -889,7 +889,7 @@
* <p>
* The format of the offset is controlled by a pattern which must be one
* of the following:
- * <p><ul>
+ * <ul>
* <li>{@code +HH} - hour only, ignoring minute and second
* <li>{@code +HHmm} - hour, with minute if non-zero, ignoring second, no colon
* <li>{@code +HH:mm} - hour, with minute if non-zero, ignoring second, with colon
@@ -899,7 +899,7 @@
* <li>{@code +HH:MM:ss} - hour and minute, with second if non-zero, with colon
* <li>{@code +HHMMSS} - hour, minute and second, no colon
* <li>{@code +HH:MM:SS} - hour, minute and second, with colon
- * </ul><p>
+ * </ul>
* The "no offset" text controls what text is printed when the total amount of
* the offset fields to be output is zero.
* Example values would be 'Z', '+00:00', 'UTC' or 'GMT'.
@@ -921,14 +921,14 @@
* This appends a localized zone offset to the builder, the format of the
* localized offset is controlled by the specified {@link FormatStyle style}
* to this method:
- * <p><ul>
+ * <ul>
* <li>{@link TextStyle#FULL full} - formats with localized offset text, such
* as 'GMT, 2-digit hour and minute field, optional second field if non-zero,
* and colon.
* <li>{@link TextStyle#SHORT short} - formats with localized offset text,
* such as 'GMT, hour without leading zero, optional 2-digit minute and
* second if non-zero, and colon.
- * </ul><p>
+ * </ul>
* <p>
* During formatting, the offset is obtained using a mechanism equivalent
* to querying the temporal with {@link TemporalQueries#offset()}.
@@ -1244,12 +1244,12 @@
* This appends a localized section to the builder, suitable for outputting
* a date, time or date-time combination. The format of the localized
* section is lazily looked up based on four items:
- * <p><ul>
+ * <ul>
* <li>the {@code dateStyle} specified to this method
* <li>the {@code timeStyle} specified to this method
* <li>the {@code Locale} of the {@code DateTimeFormatter}
* <li>the {@code Chronology}, selecting the best available
- * </ul><p>
+ * </ul>
* During formatting, the chronology is obtained from the temporal object
* being formatted, which may have been overridden by
* {@link DateTimeFormatter#withChronology(Chronology)}.
--- a/jdk/src/share/classes/java/time/temporal/IsoFields.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/temporal/IsoFields.java Thu Oct 17 10:37:23 2013 -0400
@@ -72,12 +72,10 @@
import java.time.DateTimeException;
import java.time.Duration;
import java.time.LocalDate;
-import java.time.ZoneId;
import java.time.chrono.ChronoLocalDate;
import java.time.chrono.Chronology;
import java.time.chrono.IsoChronology;
import java.time.format.ResolverStyle;
-import java.util.HashMap;
import java.util.Locale;
import java.util.Map;
import java.util.Objects;
@@ -102,11 +100,11 @@
* October, November and December are in Q4.
* <p>
* The complete date is expressed using three fields:
- * <p><ul>
+ * <ul>
* <li>{@link #DAY_OF_QUARTER DAY_OF_QUARTER} - the day within the quarter, from 1 to 90, 91 or 92
* <li>{@link #QUARTER_OF_YEAR QUARTER_OF_YEAR} - the week within the week-based-year
* <li>{@link ChronoField#YEAR YEAR} - the standard ISO year
- * </ul><p>
+ * </ul>
*
* <h3>Week based years</h3>
* The ISO-8601 standard was originally intended as a data interchange format,
@@ -114,18 +112,18 @@
* alternate way of expressing the date, based on the concept of week-based-year.
* <p>
* The date is expressed using three fields:
- * <p><ul>
+ * <ul>
* <li>{@link ChronoField#DAY_OF_WEEK DAY_OF_WEEK} - the standard field defining the
* day-of-week from Monday (1) to Sunday (7)
* <li>{@link #WEEK_OF_WEEK_BASED_YEAR} - the week within the week-based-year
* <li>{@link #WEEK_BASED_YEAR WEEK_BASED_YEAR} - the week-based-year
- * </ul><p>
+ * </ul>
* The week-based-year itself is defined relative to the standard ISO proleptic year.
* It differs from the standard year in that it always starts on a Monday.
* <p>
* The first week of a week-based-year is the first Monday-based week of the standard
* ISO year that has at least 4 days in the new year.
- * <p><ul>
+ * <ul>
* <li>If January 1st is Monday then week 1 starts on January 1st
* <li>If January 1st is Tuesday then week 1 starts on December 31st of the previous standard year
* <li>If January 1st is Wednesday then week 1 starts on December 30th of the previous standard year
@@ -133,11 +131,11 @@
* <li>If January 1st is Friday then week 1 starts on January 4th
* <li>If January 1st is Saturday then week 1 starts on January 3rd
* <li>If January 1st is Sunday then week 1 starts on January 2nd
- * </ul><p>
+ * </ul>
* There are 52 weeks in most week-based years, however on occasion there are 53 weeks.
* <p>
* For example:
- * <p>
+ *
* <table cellpadding="0" cellspacing="3" border="0" style="text-align: left; width: 50%;">
* <caption>Examples of Week based Years</caption>
* <tr><th>Date</th><th>Day-of-week</th><th>Field values</th></tr>
--- a/jdk/src/share/classes/java/time/temporal/JulianFields.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/temporal/JulianFields.java Thu Oct 17 10:37:23 2013 -0400
@@ -66,11 +66,9 @@
import static java.time.temporal.ChronoUnit.FOREVER;
import java.time.DateTimeException;
-import java.time.ZoneId;
import java.time.chrono.ChronoLocalDate;
import java.time.chrono.Chronology;
import java.time.format.ResolverStyle;
-import java.util.Collections;
import java.util.Map;
/**
@@ -116,7 +114,7 @@
* In {@linkplain ResolverStyle#STRICT strict mode} and {@linkplain ResolverStyle#SMART smart mode}
* the Julian Day value is validated against the range of valid values.
* In {@linkplain ResolverStyle#LENIENT lenient mode} no validation occurs.
- * <p>
+ *
* <h3>Astronomical and Scientific Notes</h3>
* The standard astronomical definition uses a fraction to indicate the time-of-day,
* thus 3.25 would represent the time 18:00, since days start at midday.
@@ -124,7 +122,7 @@
* The integer value for the Julian Day Number is the astronomical Julian Day value at midday
* of the date in question.
* This amounts to the astronomical Julian Day, rounded to an integer {@code JDN = floor(JD + 0.5)}.
- * <p>
+ *
* <pre>
* | ISO date | Julian Day Number | Astronomical Julian Day |
* | 1970-01-01T00:00 | 2,440,588 | 2,440,587.5 |
@@ -164,7 +162,7 @@
* In {@linkplain ResolverStyle#STRICT strict mode} and {@linkplain ResolverStyle#SMART smart mode}
* the Modified Julian Day value is validated against the range of valid values.
* In {@linkplain ResolverStyle#LENIENT lenient mode} no validation occurs.
- * <p>
+ *
* <h3>Astronomical and Scientific Notes</h3>
* <pre>
* | ISO date | Modified Julian Day | Decimal MJD |
@@ -176,7 +174,7 @@
* | 1970-01-02T06:00 | 40,588 | 40,588.25 |
* | 1970-01-02T12:00 | 40,588 | 40,588.5 |
* </pre>
- * <p>
+ *
* Modified Julian Days are sometimes taken to imply Universal Time or UTC, but this
* implementation always uses the Modified Julian Day for the local date,
* regardless of the offset or time-zone.
--- a/jdk/src/share/classes/java/time/temporal/Temporal.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/temporal/Temporal.java Thu Oct 17 10:37:23 2013 -0400
@@ -95,15 +95,15 @@
* <h3>When to implement</h3>
* <p>
* A class should implement this interface if it meets three criteria:
- * <p><ul>
+ * <ul>
* <li>it provides access to date/time/offset information, as per {@code TemporalAccessor}
* <li>the set of fields are contiguous from the largest to the smallest
* <li>the set of fields are complete, such that no other field is needed to define the
* valid range of values for the fields that are represented
- * </ul><p>
+ * </ul>
* <p>
* Four examples make this clear:
- * <p><ul>
+ * <ul>
* <li>{@code LocalDate} implements this interface as it represents a set of fields
* that are contiguous from days to forever and require no external information to determine
* the validity of each date. It is therefore able to implement plus/minus correctly.
@@ -117,7 +117,7 @@
* <li>The combination day-of-week and day-of-month ("Friday the 13th") should not implement
* this interface. It does not represent a contiguous set of fields, as days to weeks overlaps
* days to months.
- * </ul><p>
+ * </ul>
*
* @implSpec
* This interface places no restrictions on the mutability of implementations,
--- a/jdk/src/share/classes/java/time/temporal/WeekFields.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/temporal/WeekFields.java Thu Oct 17 10:37:23 2013 -0400
@@ -64,7 +64,6 @@
import static java.time.temporal.ChronoField.DAY_OF_MONTH;
import static java.time.temporal.ChronoField.DAY_OF_WEEK;
import static java.time.temporal.ChronoField.DAY_OF_YEAR;
-import static java.time.temporal.ChronoField.EPOCH_DAY;
import static java.time.temporal.ChronoField.MONTH_OF_YEAR;
import static java.time.temporal.ChronoField.YEAR;
import static java.time.temporal.ChronoUnit.DAYS;
@@ -77,12 +76,9 @@
import java.io.Serializable;
import java.time.DateTimeException;
import java.time.DayOfWeek;
-import java.time.ZoneId;
import java.time.chrono.ChronoLocalDate;
import java.time.chrono.Chronology;
import java.time.format.ResolverStyle;
-import java.util.Collections;
-import java.util.HashMap;
import java.util.Locale;
import java.util.Map;
import java.util.Objects;
@@ -119,16 +115,16 @@
* For example, the ISO-8601 standard considers Monday to be the first day-of-week.
* <li>The minimal number of days in the first week.
* For example, the ISO-8601 standard counts the first week as needing at least 4 days.
- * </ul><p>
+ * </ul>
* Together these two values allow a year or month to be divided into weeks.
- * <p>
+ *
* <h3>Week of Month</h3>
* One field is used: week-of-month.
* The calculation ensures that weeks never overlap a month boundary.
* The month is divided into periods where each period starts on the defined first day-of-week.
* The earliest period is referred to as week 0 if it has less than the minimal number of days
* and week 1 if it has at least the minimal number of days.
- * <p>
+ *
* <table cellpadding="0" cellspacing="3" border="0" style="text-align: left; width: 50%;">
* <caption>Examples of WeekFields</caption>
* <tr><th>Date</th><td>Day-of-week</td>
--- a/jdk/src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java Thu Oct 17 10:37:23 2013 -0400
@@ -83,12 +83,12 @@
* <p>
* This class allows rules for identifying future transitions to be expressed.
* A rule might be written in many forms:
- * <p><ul>
+ * <ul>
* <li>the 16th March
* <li>the Sunday on or after the 16th March
* <li>the Sunday on or before the 16th March
* <li>the last Sunday in February
- * </ul><p>
+ * </ul>
* These different rule types can be expressed and queried.
*
* @implSpec
@@ -575,11 +575,11 @@
* transition date-time.
* <p>
* Time zone rules are expressed in one of three ways:
- * <p><ul>
+ * <ul>
* <li>Relative to UTC</li>
* <li>Relative to the standard offset in force</li>
* <li>Relative to the wall offset (what you would see on a clock on the wall)</li>
- * </ul><p>
+ * </ul>
*/
public static enum TimeDefinition {
/** The local date-time is expressed in terms of the UTC offset. */
--- a/jdk/src/share/classes/java/time/zone/ZoneRules.java Wed Oct 16 17:55:49 2013 -0400
+++ b/jdk/src/share/classes/java/time/zone/ZoneRules.java Thu Oct 17 10:37:23 2013 -0400
@@ -508,7 +508,7 @@
* <p>
* The mapping from a local date-time to an offset is not straightforward.
* There are three cases:
- * <p><ul>
+ * <ul>
* <li>Normal, with one valid offset. For the vast majority of the year, the normal
* case applies, where there is a single valid offset for the local date-time.</li>
* <li>Gap, with zero valid offsets. This is when clocks jump forward typically
@@ -517,7 +517,7 @@
* <li>Overlap, with two valid offsets. This is when clocks are set back typically
* due to the autumn daylight savings change from "summer" to "winter".
* In an overlap there are local date-time values with two valid offsets.</li>
- * </ul><p>
+ * </ul>
* Thus, for any given local date-time there can be zero, one or two valid offsets.
* This method returns the single offset in the Normal case, and in the Gap or Overlap
* case it returns the offset before the transition.
@@ -544,7 +544,7 @@
* <p>
* The mapping from a local date-time to an offset is not straightforward.
* There are three cases:
- * <p><ul>
+ * <ul>
* <li>Normal, with one valid offset. For the vast majority of the year, the normal
* case applies, where there is a single valid offset for the local date-time.</li>
* <li>Gap, with zero valid offsets. This is when clocks jump forward typically
@@ -553,7 +553,7 @@
* <li>Overlap, with two valid offsets. This is when clocks are set back typically
* due to the autumn daylight savings change from "summer" to "winter".
* In an overlap there are local date-time values with two valid offsets.</li>
- * </ul><p>
+ * </ul>
* Thus, for any given local date-time there can be zero, one or two valid offsets.
* This method returns that list of valid offsets, which is a list of size 0, 1 or 2.
* In the case where there are two offsets, the earlier offset is returned at index 0
@@ -595,7 +595,7 @@
* <p>
* The mapping from a local date-time to an offset is not straightforward.
* There are three cases:
- * <p><ul>
+ * <ul>
* <li>Normal, with one valid offset. For the vast majority of the year, the normal
* case applies, where there is a single valid offset for the local date-time.</li>
* <li>Gap, with zero valid offsets. This is when clocks jump forward typically
@@ -604,7 +604,7 @@
* <li>Overlap, with two valid offsets. This is when clocks are set back typically
* due to the autumn daylight savings change from "summer" to "winter".
* In an overlap there are local date-time values with two valid offsets.</li>
- * </ul><p>
+ * </ul>
* A transition is used to model the cases of a Gap or Overlap.
* The Normal case will return null.
* <p>