This set of fields provide field-based access to manipulate a date, time or date-time.
The standard set of fields can be extended by implementing TemporalField
.
These fields are intended to be applicable in multiple calendar systems. For example, most non-ISO calendar systems define dates as a year, month and day, just with slightly different rules. The documentation of each field explains how it operates.
Implementation Specification
This is a final, immutable and thread-safe enum.
Modifier and Type | Field and Description |
---|---|
public static final ChronoField | ALIGNED_DAY_OF_WEEK_IN_MONTH
The aligned day-of-week within a month. |
public static final ChronoField | ALIGNED_DAY_OF_WEEK_IN_YEAR
The aligned day-of-week within a year. |
public static final ChronoField | ALIGNED_WEEK_OF_MONTH
The aligned week within a month. |
public static final ChronoField | ALIGNED_WEEK_OF_YEAR
The aligned week within a year. |
public static final ChronoField | AMPM_OF_DAY
The am-pm-of-day. |
private final TemporalUnit | |
public static final ChronoField | CLOCK_HOUR_OF_AMPM
The clock-hour-of-am-pm. |
public static final ChronoField | CLOCK_HOUR_OF_DAY
The clock-hour-of-day. |
public static final ChronoField | DAY_OF_MONTH
The day-of-month. |
public static final ChronoField | DAY_OF_WEEK
The day-of-week, such as Tuesday. |
public static final ChronoField | DAY_OF_YEAR
The day-of-year. |
private final String | |
public static final ChronoField | EPOCH_DAY
The epoch-day, based on the Java epoch of 1970-01-01 (ISO). |
public static final ChronoField | ERA
The era. |
public static final ChronoField | HOUR_OF_AMPM
The hour-of-am-pm. |
public static final ChronoField | HOUR_OF_DAY
The hour-of-day. |
public static final ChronoField | INSTANT_SECONDS
The instant epoch-seconds. |
public static final ChronoField | MICRO_OF_DAY
The micro-of-day. |
public static final ChronoField | MICRO_OF_SECOND
The micro-of-second. |
public static final ChronoField | MILLI_OF_DAY
The milli-of-day. |
public static final ChronoField | MILLI_OF_SECOND
The milli-of-second. |
public static final ChronoField | MINUTE_OF_DAY
The minute-of-day. |
public static final ChronoField | MINUTE_OF_HOUR
The minute-of-hour. |
public static final ChronoField | MONTH_OF_YEAR
The month-of-year, such as March. |
private final String | name
Hides java. |
public static final ChronoField | NANO_OF_DAY
The nano-of-day. |
public static final ChronoField | NANO_OF_SECOND
The nano-of-second. |
public static final ChronoField | OFFSET_SECONDS
The offset from UTC/Greenwich. |
public static final ChronoField | PROLEPTIC_MONTH
The proleptic-month based, counting months sequentially from year 0. |
private final ValueRange | |
private final TemporalUnit | |
public static final ChronoField | SECOND_OF_DAY
The second-of-day. |
public static final ChronoField | SECOND_OF_MINUTE
The second-of-minute. |
public static final ChronoField | YEAR
The proleptic year, such as 2012. |
public static final ChronoField | YEAR_OF_ERA
The year within the era. |
Access | Constructor and Description |
---|---|
private | |
private | ChronoField(String name, TemporalUnit baseUnit, TemporalUnit rangeUnit, ValueRange range, String displayNameKey)
|
Modifier and Type | Method and Description |
---|---|
public <R extends Temporal> R | adjustInto(R
the temporal object to adjust, not null temporal, long the new value of the field newValue)Implements java. |
public int | Returns: the value that was passed inthe value to check value)Checks that the specified value is valid and fits in an |
public long | Returns: the value that was passed inthe value to check value)Checks that the specified value is valid for this field. |
public TemporalUnit | getBaseUnit()
Implements java. The unit of the field is the period that varies within the range. |
public String | getDisplayName(Locale
the locale to use, not null locale)Overrides default java. |
public long | getFrom(TemporalAccessor
the temporal object to query, not null temporal)Implements java. |
public TemporalUnit | getRangeUnit()
Implements java. |
public boolean | Returns: true if it is a component of a dateImplements java. |
public boolean | isSupportedBy(TemporalAccessor
the temporal object to query, not null temporal)Implements java. |
public boolean | Returns: true if it is a component of a timeImplements java. |
public ValueRange | Returns: the range of valid values for the field, not nullImplements java. |
public ValueRange | rangeRefinedBy(TemporalAccessor
the temporal object used to refine the result, not null temporal)Implements java. |
public String | toString()
Overrides java. Implements java. |
public static ChronoField | |
public static ChronoField[] |
ALIGNED_DAY_OF_WEEK_IN_MONTH | back to summary |
---|---|
public static final ChronoField ALIGNED_DAY_OF_WEEK_IN_MONTH The aligned day-of-week within a month.
This represents concept of the count of days within the period of a week
where the weeks are aligned to the start of the month.
This field is typically used with For example, in a calendar systems with a seven day week, the first aligned-week-of-month starts on day-of-month 1, the second aligned-week starts on day-of-month 8, and so on. Within each of these aligned-weeks, the days are numbered from 1 to 7 and returned as the value of this field. As such, day-of-month 1 to 7 will have aligned-day-of-week values from 1 to 7. And day-of-month 8 to 14 will repeat this with aligned-day-of-week values from 1 to 7. Calendar systems that do not have a seven day week should typically implement this field in the same way, but using the alternate week length. |
ALIGNED_DAY_OF_WEEK_IN_YEAR | back to summary |
---|---|
public static final ChronoField ALIGNED_DAY_OF_WEEK_IN_YEAR The aligned day-of-week within a year.
This represents concept of the count of days within the period of a week
where the weeks are aligned to the start of the year.
This field is typically used with For example, in a calendar systems with a seven day week, the first aligned-week-of-year starts on day-of-year 1, the second aligned-week starts on day-of-year 8, and so on. Within each of these aligned-weeks, the days are numbered from 1 to 7 and returned as the value of this field. As such, day-of-year 1 to 7 will have aligned-day-of-week values from 1 to 7. And day-of-year 8 to 14 will repeat this with aligned-day-of-week values from 1 to 7. Calendar systems that do not have a seven day week should typically implement this field in the same way, but using the alternate week length. |
ALIGNED_WEEK_OF_MONTH | back to summary |
---|---|
public static final ChronoField ALIGNED_WEEK_OF_MONTH The aligned week within a month.
This represents concept of the count of weeks within the period of a month
where the weeks are aligned to the start of the month.
This field is typically used with For example, in a calendar systems with a seven day week, the first aligned-week-of-month starts on day-of-month 1, the second aligned-week starts on day-of-month 8, and so on. Thus, day-of-month values 1 to 7 are in aligned-week 1, while day-of-month values 8 to 14 are in aligned-week 2, and so on. Calendar systems that do not have a seven day week should typically implement this field in the same way, but using the alternate week length. |
ALIGNED_WEEK_OF_YEAR | back to summary |
---|---|
public static final ChronoField ALIGNED_WEEK_OF_YEAR The aligned week within a year.
This represents concept of the count of weeks within the period of a year
where the weeks are aligned to the start of the year.
This field is typically used with For example, in a calendar systems with a seven day week, the first aligned-week-of-year starts on day-of-year 1, the second aligned-week starts on day-of-year 8, and so on. Thus, day-of-year values 1 to 7 are in aligned-week 1, while day-of-year values 8 to 14 are in aligned-week 2, and so on. Calendar systems that do not have a seven day week should typically implement this field in the same way, but using the alternate week length. |
AMPM_OF_DAY | back to summary |
---|---|
public static final ChronoField AMPM_OF_DAY The am-pm-of-day. This counts the AM/PM within the day, from 0 (AM) to 1 (PM). This field has the same meaning for all calendar systems.
When parsing this field it behaves equivalent to the following:
The value is validated from 0 to 1 in strict and smart mode.
In lenient mode the value is not validated. It is combined with
|
baseUnit | back to summary |
---|---|
private final TemporalUnit baseUnit |
CLOCK_HOUR_OF_AMPM | back to summary |
---|---|
public static final ChronoField CLOCK_HOUR_OF_AMPM The clock-hour-of-am-pm. This counts the hour within the AM/PM, from 1 to 12. This is the hour that would be observed on a standard 12-hour analog wall clock. This field has the same meaning for all calendar systems.
When parsing this field it behaves equivalent to the following:
The value is validated from 1 to 12 in strict mode and from
0 to 12 in smart mode. In lenient mode the value is not validated.
The field is converted to an
See |
CLOCK_HOUR_OF_DAY | back to summary |
---|---|
public static final ChronoField CLOCK_HOUR_OF_DAY The clock-hour-of-day. This counts the hour within the day, from 1 to 24. This is the hour that would be observed on a 24-hour analog wall clock. This field has the same meaning for all calendar systems.
When parsing this field it behaves equivalent to the following:
The value is validated from 1 to 24 in strict mode and from
0 to 24 in smart mode. In lenient mode the value is not validated.
The field is converted to an
See |
DAY_OF_MONTH | back to summary |
---|---|
public static final ChronoField DAY_OF_MONTH The day-of-month. This represents the concept of the day within the month. In the default ISO calendar system, this has values from 1 to 31 in most months. April, June, September, November have days from 1 to 30, while February has days from 1 to 28, or 29 in a leap year. Non-ISO calendar systems should implement this field using the most recognized day-of-month values for users of the calendar system. Normally, this is a count of days from 1 to the length of the month. |
DAY_OF_WEEK | back to summary |
---|---|
public static final ChronoField DAY_OF_WEEK The day-of-week, such as Tuesday.
This represents the standard concept of the day of the week.
In the default ISO calendar system, this has values from Monday (1) to Sunday (7).
The
Most non-ISO calendar systems also define a seven day week that aligns with ISO.
Those calendar systems must also use the same numbering system, from Monday (1) to
Sunday (7), which allows Calendar systems that do not have a standard seven day week should implement this field if they have a similar concept of named or numbered days within a period similar to a week. It is recommended that the numbering starts from 1. |
DAY_OF_YEAR | back to summary |
---|---|
public static final ChronoField DAY_OF_YEAR The day-of-year. This represents the concept of the day within the year. In the default ISO calendar system, this has values from 1 to 365 in standard years and 1 to 366 in leap years. Non-ISO calendar systems should implement this field using the most recognized day-of-year values for users of the calendar system. Normally, this is a count of days from 1 to the length of the year. Note that a non-ISO calendar system may have year numbering system that changes at a different point to the natural reset in the month numbering. An example of this is the Japanese calendar system where a change of era, which resets the year number to 1, can happen on any date. The era and year reset also cause the day-of-year to be reset to 1, but not the month-of-year or day-of-month. |
displayNameKey | back to summary |
---|---|
private final String displayNameKey |
EPOCH_DAY | back to summary |
---|---|
public static final ChronoField EPOCH_DAY The epoch-day, based on the Java epoch of 1970-01-01 (ISO). This field is the sequential count of days where 1970-01-01 (ISO) is zero. Note that this uses the local time-line, ignoring offset and time-zone. This field is strictly defined to have the same meaning in all calendar systems. This is necessary to ensure interoperation between calendars. Range of EpochDay is between (LocalDate.MIN.toEpochDay(), LocalDate.MAX.toEpochDay()) both inclusive. |
ERA | back to summary |
---|---|
public static final ChronoField ERA The era.
This represents the concept of the era, which is the largest division of the time-line.
This field is typically used with
In the default ISO calendar system, there are two eras defined, 'BCE' and 'CE'.
The era 'CE' is the one currently in use and year-of-era runs from 1 to the maximum value.
The era 'BCE' is the previous era, and the year-of-era runs backwards.
See Non-ISO calendar systems should implement this field to define eras. The value of the era that was active on 1970-01-01 (ISO) must be assigned the value 1. Earlier eras must have sequentially smaller values. Later eras must have sequentially larger values, |
HOUR_OF_AMPM | back to summary |
---|---|
public static final ChronoField HOUR_OF_AMPM The hour-of-am-pm. This counts the hour within the AM/PM, from 0 to 11. This is the hour that would be observed on a standard 12-hour digital clock. This field has the same meaning for all calendar systems.
When parsing this field it behaves equivalent to the following:
The value is validated from 0 to 11 in strict and smart mode.
In lenient mode the value is not validated. It is combined with
See |
HOUR_OF_DAY | back to summary |
---|---|
public static final ChronoField HOUR_OF_DAY The hour-of-day. This counts the hour within the day, from 0 to 23. This is the hour that would be observed on a standard 24-hour digital clock. This field has the same meaning for all calendar systems.
When parsing this field it behaves equivalent to the following:
The value is validated in strict and smart mode but not in lenient mode.
The field is combined with
See |
INSTANT_SECONDS | back to summary |
---|---|
public static final ChronoField INSTANT_SECONDS The instant epoch-seconds.
This represents the concept of the sequential count of seconds where
1970-01-01T00:00Z (ISO) is zero.
This field may be used with
An This field is strictly defined to have the same meaning in all calendar systems. This is necessary to ensure interoperation between calendars. |
MICRO_OF_DAY | back to summary |
---|---|
public static final ChronoField MICRO_OF_DAY The micro-of-day. This counts the microsecond within the day, from 0 to (24 * 60 * 60 * 1,000,000) - 1. This field has the same meaning for all calendar systems.
This field is used to represent the micro-of-day handling any fraction of the second.
Implementations of
When this field is used for setting a value, it should behave in the same way as
setting
When parsing this field it behaves equivalent to the following:
The value is validated in strict and smart mode but not in lenient mode.
The value is split to form |
MICRO_OF_SECOND | back to summary |
---|---|
public static final ChronoField MICRO_OF_SECOND The micro-of-second. This counts the microsecond within the second, from 0 to 999,999. This field has the same meaning for all calendar systems.
This field is used to represent the micro-of-second handling any fraction of the second.
Implementations of
When this field is used for setting a value, it should behave in the same way as
setting
When parsing this field it behaves equivalent to the following:
The value is validated in strict and smart mode but not in lenient mode.
The field is resolved in combination with |
MILLI_OF_DAY | back to summary |
---|---|
public static final ChronoField MILLI_OF_DAY The milli-of-day. This counts the millisecond within the day, from 0 to (24 * 60 * 60 * 1,000) - 1. This field has the same meaning for all calendar systems.
This field is used to represent the milli-of-day handling any fraction of the second.
Implementations of
When this field is used for setting a value, it should behave in the same way as
setting
When parsing this field it behaves equivalent to the following:
The value is validated in strict and smart mode but not in lenient mode.
The value is split to form |
MILLI_OF_SECOND | back to summary |
---|---|
public static final ChronoField MILLI_OF_SECOND The milli-of-second. This counts the millisecond within the second, from 0 to 999. This field has the same meaning for all calendar systems.
This field is used to represent the milli-of-second handling any fraction of the second.
Implementations of
When this field is used for setting a value, it should behave in the same way as
setting
When parsing this field it behaves equivalent to the following:
The value is validated in strict and smart mode but not in lenient mode.
The field is resolved in combination with |
MINUTE_OF_DAY | back to summary |
---|---|
public static final ChronoField MINUTE_OF_DAY The minute-of-day. This counts the minute within the day, from 0 to (24 * 60) - 1. This field has the same meaning for all calendar systems.
When parsing this field it behaves equivalent to the following:
The value is validated in strict and smart mode but not in lenient mode.
The value is split to form |
MINUTE_OF_HOUR | back to summary |
---|---|
public static final ChronoField MINUTE_OF_HOUR The minute-of-hour. This counts the minute within the hour, from 0 to 59. This field has the same meaning for all calendar systems. When parsing this field it behaves equivalent to the following: The value is validated in strict and smart mode but not in lenient mode. |
MONTH_OF_YEAR | back to summary |
---|---|
public static final ChronoField MONTH_OF_YEAR The month-of-year, such as March. This represents the concept of the month within the year. In the default ISO calendar system, this has values from January (1) to December (12). Non-ISO calendar systems should implement this field using the most recognized month-of-year values for users of the calendar system. Normally, this is a count of months starting from 1. |
name | back to summary |
---|---|
private final String name Hides java. |
NANO_OF_DAY | back to summary |
---|---|
public static final ChronoField NANO_OF_DAY The nano-of-day. This counts the nanosecond within the day, from 0 to (24 * 60 * 60 * 1,000,000,000) - 1. This field has the same meaning for all calendar systems.
This field is used to represent the nano-of-day handling any fraction of the second.
Implementations of
When parsing this field it behaves equivalent to the following:
The value is validated in strict and smart mode but not in lenient mode.
The value is split to form |
NANO_OF_SECOND | back to summary |
---|---|
public static final ChronoField NANO_OF_SECOND The nano-of-second. This counts the nanosecond within the second, from 0 to 999,999,999. This field has the same meaning for all calendar systems.
This field is used to represent the nano-of-second handling any fraction of the second.
Implementations of
When this field is used for setting a value, it should set as much precision as the
object stores, using integer division to remove excess precision.
For example, if the
When parsing this field it behaves equivalent to the following:
The value is validated in strict and smart mode but not in lenient mode.
The field is resolved in combination with |
OFFSET_SECONDS | back to summary |
---|---|
public static final ChronoField OFFSET_SECONDS The offset from UTC/Greenwich. This represents the concept of the offset in seconds of local time from UTC/Greenwich.
A This field is strictly defined to have the same meaning in all calendar systems. This is necessary to ensure interoperation between calendars. |
PROLEPTIC_MONTH | back to summary |
---|---|
public static final ChronoField PROLEPTIC_MONTH The proleptic-month based, counting months sequentially from year 0. This field is the sequential count of months where the first month in proleptic-year zero has the value zero. Later months have increasingly larger values. Earlier months have increasingly small values. There are no gaps or breaks in the sequence of months. Note that this uses the local time-line, ignoring offset and time-zone.
In the default ISO calendar system, June 2012 would have the value
Non-ISO calendar systems must implement this field as per the definition above. It is just a simple zero-based count of elapsed months from the start of proleptic-year 0. All calendar systems with a full proleptic-year definition will have a year zero. If the calendar system has a minimum year that excludes year zero, then one must be extrapolated in order for this method to be defined. |
range | back to summary |
---|---|
private final ValueRange range |
rangeUnit | back to summary |
---|---|
private final TemporalUnit rangeUnit |
SECOND_OF_DAY | back to summary |
---|---|
public static final ChronoField SECOND_OF_DAY The second-of-day. This counts the second within the day, from 0 to (24 * 60 * 60) - 1. This field has the same meaning for all calendar systems.
When parsing this field it behaves equivalent to the following:
The value is validated in strict and smart mode but not in lenient mode.
The value is split to form |
SECOND_OF_MINUTE | back to summary |
---|---|
public static final ChronoField SECOND_OF_MINUTE The second-of-minute. This counts the second within the minute, from 0 to 59. This field has the same meaning for all calendar systems. When parsing this field it behaves equivalent to the following: The value is validated in strict and smart mode but not in lenient mode. |
YEAR | back to summary |
---|---|
public static final ChronoField YEAR The proleptic year, such as 2012.
This represents the concept of the year, counting sequentially and using negative numbers.
The proleptic year is not interpreted in terms of the era.
See
The standard mental model for a date is based on three concepts - year, month and day.
These map onto the Non-ISO calendar systems should implement this field as follows. If the calendar system has only two eras, before and after a fixed date, then the proleptic-year value must be the same as the year-of-era value for the later era, and increasingly negative for the earlier era. If the calendar system has more than two eras, then the proleptic-year value may be defined with any appropriate value, although defining it to be the same as ISO may be the best option. |
YEAR_OF_ERA | back to summary |
---|---|
public static final ChronoField YEAR_OF_ERA The year within the era.
This represents the concept of the year within the era.
This field is typically used with
The standard mental model for a date is based on three concepts - year, month and day.
These map onto the In the default ISO calendar system, there are two eras defined, 'BCE' and 'CE'. The era 'CE' is the one currently in use and year-of-era runs from 1 to the maximum value. The era 'BCE' is the previous era, and the year-of-era runs backwards.
For example, subtracting a year each time yield the following: Note that the ISO-8601 standard does not actually define eras. Note also that the ISO eras do not align with the well-known AD/BC eras due to the change between the Julian and Gregorian calendar systems. Non-ISO calendar systems should implement this field using the most recognized year-of-era value for users of the calendar system. Since most calendar systems have only two eras, the year-of-era numbering approach will typically be the same as that used by the ISO calendar system. The year-of-era value should typically always be positive, however this is not required. |
ChronoField | back to summary |
---|---|
private ChronoField(String name, TemporalUnit baseUnit, TemporalUnit rangeUnit, ValueRange range) |
ChronoField | back to summary |
---|---|
private ChronoField(String name, TemporalUnit baseUnit, TemporalUnit rangeUnit, ValueRange range, String displayNameKey) |
adjustInto | back to summary |
---|---|
public <R extends Temporal> R adjustInto(R temporal, long newValue) Implements java. Doc from java. 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 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 // these two lines are equivalent, but the second approach is recommended temporal = thisField.adjustInto(temporal); temporal = temporal.with(thisField);It is recommended to use the second approach, with(TemporalField) ,
as it is a lot clearer to read in code.
Implementations should perform any queries or calculations using the fields
available in 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.
|
checkValidIntValue | back to summary |
---|---|
public int checkValidIntValue(long value) Checks that the specified value is valid and fits in an
This validates that the value is within the outer range of valid values
returned by
This method checks against the range of the field in the ISO-8601 calendar system.
This range may be incorrect for other calendar systems.
Use
|
checkValidValue | back to summary |
---|---|
public long checkValidValue(long value) Checks that the specified value is valid for this field.
This validates that the value is within the outer range of valid values
returned by
This method checks against the range of the field in the ISO-8601 calendar system.
This range may be incorrect for other calendar systems.
Use
|
getBaseUnit | back to summary |
---|---|
public TemporalUnit getBaseUnit() Implements java. Doc from java. 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
|
getDisplayName | back to summary |
---|---|
public String getDisplayName(Locale locale) Overrides default java. Doc from java. Gets the display name for the field in the requested locale. If there is no display name for the locale then a suitable default must be returned.
The default implementation must check the locale is not null
and return |
getFrom | back to summary |
---|---|
public long getFrom(TemporalAccessor temporal) Implements java. Doc from java. 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 // these two lines are equivalent, but the second approach is recommended temporal = thisField.getFrom(temporal); temporal = temporal.getLong(thisField);It is recommended to use the second approach, getLong(TemporalField) ,
as it is a lot clearer to read in code.
Implementations should perform any queries or calculations using the fields
available in
|
getRangeUnit | back to summary |
---|---|
public TemporalUnit getRangeUnit() Implements java. Doc from java. 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 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'.
|
isDateBased | back to summary |
---|---|
public boolean isDateBased() Implements java. Checks if this field represents a component of a date. Fields from day-of-week to era are date-based.
|
isSupportedBy | back to summary |
---|---|
public boolean isSupportedBy(TemporalAccessor temporal) Implements java. Doc from java. Checks if this field is supported by the temporal object. This determines whether the temporal accessor supports this field. If this returns false, then 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 // these two lines are equivalent, but the second approach is recommended temporal = thisField.isSupportedBy(temporal); temporal = temporal.isSupported(thisField);It is recommended to use the second approach, isSupported(TemporalField) ,
as it is a lot clearer to read in code.
Implementations should determine whether they are supported using the fields
available in
|
isTimeBased | back to summary |
---|---|
public boolean isTimeBased() Implements java. Checks if this field represents a component of a time. Fields from nano-of-second to am-pm-of-day are time-based.
|
range | back to summary |
---|---|
public ValueRange range() Implements java. Gets the range of valid values for the field.
All fields can be expressed as a
This method returns the range of the field in the ISO-8601 calendar system.
This range may be incorrect for other calendar systems.
Use 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.
|
rangeRefinedBy | back to summary |
---|---|
public ValueRange rangeRefinedBy(TemporalAccessor temporal) Implements java. Doc from java. 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
There are two equivalent ways of using this method.
The first is to invoke this method directly.
The second is to use // these two lines are equivalent, but the second approach is recommended temporal = thisField.rangeRefinedBy(temporal); temporal = temporal.range(thisField);It is recommended to use the second approach, range(TemporalField) ,
as it is a lot clearer to read in code.
Implementations should perform any queries or calculations using the fields
available in
|
toString | back to summary |
---|---|
public String toString() Overrides java. Implements java. Doc from java. Gets a descriptive name for the field.
The should be of the format 'BaseOfRange', such as 'MonthOfYear',
unless the field has a range of |
valueOf | back to summary |
---|---|
public static ChronoField valueOf(String name) |
values | back to summary |
---|---|
public static ChronoField[] values() |