+ * Date and time is expressed using fields which partition the time-line into something + * meaningful for humans. Implementations of this interface represent those fields. + *
+ * The most commonly used units are defined in {@link ChronoField}. + * Further fields are supplied in {@link ISOFields}, {@link WeekFields} and {@link JulianFields}. + * Fields can also be written by application code by implementing this interface. + *
+ * The field works using double dispatch. Client code calls methods on a date-time like + * {@code LocalDateTime} which check if the field is a {@code ChronoField}. + * If it is, then the date-time must handle it. + * Otherwise, the method call is re-dispatched to the matching method in this interface. + * + *
+ * The should be of the format 'BaseOfRange', such as 'MonthOfYear', + * unless the field has a range of {@code FOREVER}, when only + * the base unit is mentioned, such as 'Year' or 'Era'. + * + * @return the name, not null + */ + String getName(); + + /** + * Gets the unit that the field is measured in. + *
+ * The unit of the field is the period that varies within the range. + * For example, in the field 'MonthOfYear', the unit is 'Months'. + * See also {@link #getRangeUnit()}. + * + * @return the period unit defining the base unit of the field, not null + */ + TemporalUnit getBaseUnit(); + + /** + * Gets the range that the field is bound by. + *
+ * The range of the field is the period that the field varies within. + * For example, in the field 'MonthOfYear', the range is 'Years'. + * See also {@link #getBaseUnit()}. + *
+ * The range is never null. For example, the 'Year' field is shorthand for + * 'YearOfForever'. It therefore has a unit of 'Years' and a range of 'Forever'. + * + * @return the period unit defining the range of the field, not null + */ + TemporalUnit getRangeUnit(); + + //----------------------------------------------------------------------- + /** + * Compares the value of this field in two temporal objects. + *
+ * All fields implement {@link Comparator} on {@link TemporalAccessor}. + * This allows a list of date-times to be compared using the value of a field. + * For example, you could sort a list of arbitrary temporal objects by the value of + * the month-of-year field - {@code Collections.sort(list, MONTH_OF_YEAR)} + *
+ * The default implementation must behave equivalent to this code: + *
+ * return Long.compare(temporal1.getLong(this), temporal2.getLong(this)); + *+ * + * @param temporal1 the first temporal object to compare, not null + * @param temporal2 the second temporal object to compare, not null + * @throws DateTimeException if unable to obtain the value for this field + */ + public default int compare(TemporalAccessor temporal1, TemporalAccessor temporal2) { + return Long.compare(temporal1.getLong(this), temporal2.getLong(this)); + } + + /** + * Gets the range of valid values for the field. + *
+ * All fields can be expressed as a {@code long} integer. + * This method returns an object that describes the valid range for that value. + * This method is generally only applicable to the ISO-8601 calendar system. + *
+ * Note that the result only describes the minimum and maximum valid values + * and it is important not to read too much into them. For example, there + * could be values within the range that are invalid for the field. + * + * @return the range of valid values for the field, not null + */ + ValueRange range(); + + //----------------------------------------------------------------------- + /** + * Checks if this field is supported by the temporal object. + *
+ * This determines whether the temporal accessor supports this field. + * If this returns false, the the temporal cannot be queried for this field. + *
+ * There are two equivalent ways of using this method. + * The first is to invoke this method directly. + * The second is to use {@link TemporalAccessor#isSupported(TemporalField)}: + *
+ * // these two lines are equivalent, but the second approach is recommended + * temporal = thisField.doIsSupported(temporal); + * temporal = temporal.isSupported(thisField); + *+ * It is recommended to use the second approach, {@code isSupported(TemporalField)}, + * as it is a lot clearer to read in code. + *
+ * Implementations should determine whether they are supported using the fields + * available in {@link ChronoField}. + * + * @param temporal the temporal object to query, not null + * @return true if the date-time can be queried for this field, false if not + */ + boolean doIsSupported(TemporalAccessor temporal); + + /** + * Get the range of valid values for this field using the temporal object to + * refine the result. + *
+ * This uses the temporal object to find the range of valid values for the field. + * This is similar to {@link #range()}, however this method refines the result + * using the temporal. For example, if the field is {@code DAY_OF_MONTH} the + * {@code range} method is not accurate as there are four possible month lengths, + * 28, 29, 30 and 31 days. Using this method with a date allows the range to be + * accurate, returning just one of those four options. + *
+ * There are two equivalent ways of using this method. + * The first is to invoke this method directly. + * The second is to use {@link TemporalAccessor#range(TemporalField)}: + *
+ * // these two lines are equivalent, but the second approach is recommended + * temporal = thisField.doRange(temporal); + * temporal = temporal.range(thisField); + *+ * It is recommended to use the second approach, {@code range(TemporalField)}, + * as it is a lot clearer to read in code. + *
+ * Implementations should perform any queries or calculations using the fields + * available in {@link ChronoField}. + * If the field is not supported a {@code DateTimeException} must be thrown. + * + * @param temporal the temporal object used to refine the result, not null + * @return the range of valid values for this field, not null + * @throws DateTimeException if the range for the field cannot be obtained + */ + ValueRange doRange(TemporalAccessor temporal); + + /** + * Gets the value of this field from the specified temporal object. + *
+ * This queries the temporal object for the value of this field. + *
+ * There are two equivalent ways of using this method. + * The first is to invoke this method directly. + * The second is to use {@link TemporalAccessor#getLong(TemporalField)} + * (or {@link TemporalAccessor#get(TemporalField)}): + *
+ * // these two lines are equivalent, but the second approach is recommended + * temporal = thisField.doGet(temporal); + * temporal = temporal.getLong(thisField); + *+ * It is recommended to use the second approach, {@code getLong(TemporalField)}, + * as it is a lot clearer to read in code. + *
+ * Implementations should perform any queries or calculations using the fields + * available in {@link ChronoField}. + * If the field is not supported a {@code DateTimeException} must be thrown. + * + * @param temporal the temporal object to query, not null + * @return the value of this field, not null + * @throws DateTimeException if a value for the field cannot be obtained + */ + long doGet(TemporalAccessor temporal); + + /** + * Returns a copy of the specified temporal object with the value of this field set. + *
+ * This returns a new temporal object based on the specified one with the value for + * this field changed. For example, on a {@code LocalDate}, this could be used to + * set the year, month or day-of-month. + * The returned object has the same observable type as the specified object. + *
+ * In some cases, changing a field is not fully defined. For example, if the target object is + * a date representing the 31st January, then changing the month to February would be unclear. + * In cases like this, the implementation is responsible for resolving the result. + * Typically it will choose the previous valid date, which would be the last valid + * day of February in this example. + *
+ * There are two equivalent ways of using this method. + * The first is to invoke this method directly. + * The second is to use {@link Temporal#with(TemporalField, long)}: + *
+ * // these two lines are equivalent, but the second approach is recommended + * temporal = thisField.doWith(temporal); + * temporal = temporal.with(thisField); + *+ * It is recommended to use the second approach, {@code with(TemporalField)}, + * as it is a lot clearer to read in code. + *
+ * Implementations should perform any queries or calculations using the fields + * available in {@link ChronoField}. + * If the field is not supported a {@code DateTimeException} must be thrown. + *
+ * Implementations must not alter the specified temporal object.
+ * Instead, an adjusted copy of the original must be returned.
+ * This provides equivalent, safe behavior for immutable and mutable implementations.
+ *
+ * @param
+ * This method is invoked during the resolve of the builder.
+ * Implementations should combine the associated field with others to form
+ * objects like {@code LocalDate}, {@code LocalTime} and {@code LocalDateTime}
+ *
+ * @param builder the builder to resolve, not null
+ * @param value the value of the associated field
+ * @return true if builder has been changed, false otherwise
+ * @throws DateTimeException if unable to resolve
+ */
+ boolean resolve(DateTimeBuilder builder, long value);
+
+}