The merge process aims to extract the maximum amount of information possible from this set of fields. Ideally the outcome will be a date, time or both, however there may be insufficient information to achieve this.
The process repeatedly calls the field rule {@link DateTimeFieldRule#mergeFields merge fields}and {@link DateTimeFieldRule#mergeDateTime merge date time} methods to performthe merge on each individual field. Sometimes two or more fields will combine to form a more significant field. Sometimes they will combine to form a date or time. The process stops when there no more merges can occur.
The process is based around hierarchies that can be combined. For example, QuarterOfYear and MonthOfQuarter can be combined to form MonthOfYear. Then, MonthOfYear can be combined with DayOfMonth and Year to form a date. Any fields which take part in a merge will be removed from the result as their values can be derived from the merged field.
The exact definition of which fields combine with which is chronology dependent. For example, see {@link ISOChronology}.
This method uses strict merging. This means that each value in the field-value map must be completely valid. For example, field-value mappings representing 'MonthOfYear=June' and 'DayOfMonth=32' are invalid in combination and will throw an exception. See {@link #mergeLenient()} for alternate behavior.
The merge must result in consistent values for each field, date and time. If two different values are produced an exception is thrown. For example, both Year/MonthOfYear/DayOfMonth and Year/DayOfYear will merge to form a date. If both sets of fields do not produce the same date then an exception will be thrown. @return the new instance, with merged fields, never null @throws CalendricalException if the fields cannot be merged
| |
| |