Framework-level interface defining read-write access to a temporal object, such as a date, time, offset or some combination of these.
This is the base interface type for date, time and offset objects that
are complete enough to be manipulated using plus and minus.
It is implemented by those classes that can provide and manipulate information
as fields or queries.
TemporalAccessor for the read-only version of this interface.
Most date and time information can be represented as a number.
These are modeled using
TemporalField with the number held using
long to handle large values. Year, month and day-of-month are
simple examples of fields, but they also include instant and offsets.
ChronoField for the standard set of fields.
This interface is a framework-level interface that should not be widely
used in application code. Instead, applications should create and pass
around instances of concrete types, such as
There are many reasons for this, part of which is that implementations
of this interface may be in calendar systems other than ISO.
java.time.chrono.ChronoLocalDate for a fuller discussion of the issues.
A class should implement this interface if it meets three criteria:
Four examples make this clear:
LocalDateimplements 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.
LocalTimeimplements this interface as it represents a set of fields that are contiguous from nanos to within days and require no external information to determine validity. It is able to implement plus/minus correctly, by wrapping around the day.
MonthDay, the combination of month-of-year and day-of-month, does not implement this interface. While the combination is contiguous, from days to months within years, the combination does not have sufficient information to define the valid range of values for day-of-month. As such, it is unable to implement plus/minus correctly.
This interface places no restrictions on the mutability of implementations,
however immutability is strongly recommended.
All implementations must be