Resolves parsed {@code ChronoField} values into a date during parsing.
!(p)
Most {@code TemporalField} implementations are resolved using the
resolve method on the field. By contrast, the {@code ChronoField} class
defines fields that only have meaning relative to the chronology.
As such, {@code ChronoField} date fields are resolved here _in the
context of a specific chronology.
!(p)
{@code ChronoField} instances on the ISO calendar system are resolved
as follows.
!(ul)
!(li){@code EPOCH_DAY} - If present, this is converted to a {@code LocalDate}
and all other date fields are then cross-checked against the date.
!(li){@code PROLEPTIC_MONTH} - If present, then it is split into the
{@code YEAR} and {@code MONTH_OF_YEAR}. If the mode is strict or smart
then the field is validated.
!(li){@code YEAR_OF_ERA} and {@code ERA} - If both are present, then they
are combined to form a {@code YEAR}. In lenient mode, the {@code YEAR_OF_ERA}
range is not validated, _in smart and strict mode it is. The {@code ERA} is
validated for range _in all three modes. If only the {@code YEAR_OF_ERA} is
present, and the mode is smart or lenient, then the current era (CE/AD)
is assumed. In strict mode, no era is assumed and the {@code YEAR_OF_ERA} is
left untouched. If only the {@code ERA} is present, then it is left untouched.
!(li){@code YEAR}, {@code MONTH_OF_YEAR} and {@code DAY_OF_MONTH} -
If all three are present, then they are combined to form a {@code LocalDate}.
In all three modes, the {@code YEAR} is validated. If the mode is smart or strict,
then the month and day are validated, with the day validated from 1 to 31.
If the mode is lenient, then the date is combined _in a manner equivalent to
creating a date on the first of January _in the requested year, then adding
the difference _in months, then the difference _in days.
If the mode is smart, and the day-of-month is greater than the maximum for
the year-month, then the day-of-month is adjusted to the last day-of-month.
If the mode is strict, then the three fields must form a valid date.
!(li){@code YEAR} and {@code DAY_OF_YEAR} -
If both are present, then they are combined to form a {@code LocalDate}.
In all three modes, the {@code YEAR} is validated.
If the mode is lenient, then the date is combined _in a manner equivalent to
creating a date on the first of January _in the requested year, then adding
the difference _in days.
If the mode is smart or strict, then the two fields must form a valid date.
!(li){@code YEAR}, {@code MONTH_OF_YEAR}, {@code ALIGNED_WEEK_OF_MONTH} and
{@code ALIGNED_DAY_OF_WEEK_IN_MONTH} -
If all four are present, then they are combined to form a {@code LocalDate}.
In all three modes, the {@code YEAR} is validated.
If the mode is lenient, then the date is combined _in a manner equivalent to
creating a date on the first of January _in the requested year, then adding
the difference _in months, then the difference _in weeks, then _in days.
If the mode is smart or strict, then the all four fields are validated to
their outer ranges. The date is then combined _in a manner equivalent to
creating a date on the first day of the requested year and month, then adding
the amount _in weeks and days to reach their values. If the mode is strict,
the date is additionally validated to check that the day and week adjustment
did not change the month.
!(li){@code YEAR}, {@code MONTH_OF_YEAR}, {@code ALIGNED_WEEK_OF_MONTH} and
{@code DAY_OF_WEEK} - If all four are present, then they are combined to
form a {@code LocalDate}. The approach is the same as described above for
years, months and weeks _in {@code ALIGNED_DAY_OF_WEEK_IN_MONTH}.
The day-of-week is adjusted as the next or same matching day-of-week once
the years, months and weeks have been handled.
!(li){@code YEAR}, {@code ALIGNED_WEEK_OF_YEAR} and {@code ALIGNED_DAY_OF_WEEK_IN_YEAR} -
If all three are present, then they are combined to form a {@code LocalDate}.
In all three modes, the {@code YEAR} is validated.
If the mode is lenient, then the date is combined _in a manner equivalent to
creating a date on the first of January _in the requested year, then adding
the difference _in weeks, then _in days.
If the mode is smart or strict, then the all three fields are validated to
their outer ranges. The date is then combined _in a manner equivalent to
creating a date on the first day of the requested year, then adding
the amount _in weeks and days to reach their values. If the mode is strict,
the date is additionally validated to check that the day and week adjustment
did not change the year.
!(li){@code YEAR}, {@code ALIGNED_WEEK_OF_YEAR} and {@code DAY_OF_WEEK} -
If all three are present, then they are combined to form a {@code LocalDate}.
The approach is the same as described above for years and weeks _in
{@code ALIGNED_DAY_OF_WEEK_IN_YEAR}. The day-of-week is adjusted as the
next or same matching day-of-week once the years and weeks have been handled.
</ul>
@param fieldValues the map of fields to values, which can be updated, not null
@param resolverStyle the requested type of resolve, not null
@return the resolved date, null if insufficient information to create a date
@throws DateTimeException if the date cannot be resolved, typically
because of a conflict _in the input data
Resolves parsed {@code ChronoField} values into a date during parsing. !(p) Most {@code TemporalField} implementations are resolved using the resolve method on the field. By contrast, the {@code ChronoField} class defines fields that only have meaning relative to the chronology. As such, {@code ChronoField} date fields are resolved here _in the context of a specific chronology. !(p) {@code ChronoField} instances on the ISO calendar system are resolved as follows. !(ul) !(li){@code EPOCH_DAY} - If present, this is converted to a {@code LocalDate} and all other date fields are then cross-checked against the date. !(li){@code PROLEPTIC_MONTH} - If present, then it is split into the {@code YEAR} and {@code MONTH_OF_YEAR}. If the mode is strict or smart then the field is validated. !(li){@code YEAR_OF_ERA} and {@code ERA} - If both are present, then they are combined to form a {@code YEAR}. In lenient mode, the {@code YEAR_OF_ERA} range is not validated, _in smart and strict mode it is. The {@code ERA} is validated for range _in all three modes. If only the {@code YEAR_OF_ERA} is present, and the mode is smart or lenient, then the current era (CE/AD) is assumed. In strict mode, no era is assumed and the {@code YEAR_OF_ERA} is left untouched. If only the {@code ERA} is present, then it is left untouched. !(li){@code YEAR}, {@code MONTH_OF_YEAR} and {@code DAY_OF_MONTH} - If all three are present, then they are combined to form a {@code LocalDate}. In all three modes, the {@code YEAR} is validated. If the mode is smart or strict, then the month and day are validated, with the day validated from 1 to 31. If the mode is lenient, then the date is combined _in a manner equivalent to creating a date on the first of January _in the requested year, then adding the difference _in months, then the difference _in days. If the mode is smart, and the day-of-month is greater than the maximum for the year-month, then the day-of-month is adjusted to the last day-of-month. If the mode is strict, then the three fields must form a valid date. !(li){@code YEAR} and {@code DAY_OF_YEAR} - If both are present, then they are combined to form a {@code LocalDate}. In all three modes, the {@code YEAR} is validated. If the mode is lenient, then the date is combined _in a manner equivalent to creating a date on the first of January _in the requested year, then adding the difference _in days. If the mode is smart or strict, then the two fields must form a valid date. !(li){@code YEAR}, {@code MONTH_OF_YEAR}, {@code ALIGNED_WEEK_OF_MONTH} and {@code ALIGNED_DAY_OF_WEEK_IN_MONTH} - If all four are present, then they are combined to form a {@code LocalDate}. In all three modes, the {@code YEAR} is validated. If the mode is lenient, then the date is combined _in a manner equivalent to creating a date on the first of January _in the requested year, then adding the difference _in months, then the difference _in weeks, then _in days. If the mode is smart or strict, then the all four fields are validated to their outer ranges. The date is then combined _in a manner equivalent to creating a date on the first day of the requested year and month, then adding the amount _in weeks and days to reach their values. If the mode is strict, the date is additionally validated to check that the day and week adjustment did not change the month. !(li){@code YEAR}, {@code MONTH_OF_YEAR}, {@code ALIGNED_WEEK_OF_MONTH} and {@code DAY_OF_WEEK} - If all four are present, then they are combined to form a {@code LocalDate}. The approach is the same as described above for years, months and weeks _in {@code ALIGNED_DAY_OF_WEEK_IN_MONTH}. The day-of-week is adjusted as the next or same matching day-of-week once the years, months and weeks have been handled. !(li){@code YEAR}, {@code ALIGNED_WEEK_OF_YEAR} and {@code ALIGNED_DAY_OF_WEEK_IN_YEAR} - If all three are present, then they are combined to form a {@code LocalDate}. In all three modes, the {@code YEAR} is validated. If the mode is lenient, then the date is combined _in a manner equivalent to creating a date on the first of January _in the requested year, then adding the difference _in weeks, then _in days. If the mode is smart or strict, then the all three fields are validated to their outer ranges. The date is then combined _in a manner equivalent to creating a date on the first day of the requested year, then adding the amount _in weeks and days to reach their values. If the mode is strict, the date is additionally validated to check that the day and week adjustment did not change the year. !(li){@code YEAR}, {@code ALIGNED_WEEK_OF_YEAR} and {@code DAY_OF_WEEK} - If all three are present, then they are combined to form a {@code LocalDate}. The approach is the same as described above for years and weeks _in {@code ALIGNED_DAY_OF_WEEK_IN_YEAR}. The day-of-week is adjusted as the next or same matching day-of-week once the years and weeks have been handled. </ul>
@param fieldValues the map of fields to values, which can be updated, not null @param resolverStyle the requested type of resolve, not null @return the resolved date, null if insufficient information to create a date @throws DateTimeException if the date cannot be resolved, typically because of a conflict _in the input data