Most applications should declare method signatures, fields and variables
as LocalDate, not this interface.
A ChronoLocalDate is the abstract representation of a date where the
Chronology chronology, or calendar system, is pluggable.
The date is defined in terms of fields expressed by TemporalField,
where most common implementations are defined in ChronoField.
The chronology defines how the calendar system operates and the meaning of
the standard fields.
LocalDate rather than this
interface, even in the case where the application needs to deal with multiple
calendar systems.
This concept can seem surprising at first, as the natural way to globalize an
application might initially appear to be to abstract the calendar system.
However, as explored below, abstracting the calendar system is usually the wrong
approach, resulting in logic errors and hard to find bugs.
As such, it should be considered an application-wide architectural decision to choose
to use this interface as opposed to LocalDate.
1) Applications using this interface, as opposed to using just LocalDate,
face a significantly higher probability of bugs. This is because the calendar system
in use is not known at development time. A key cause of bugs is where the developer
applies assumptions from their day-to-day knowledge of the ISO calendar system
to code that is intended to deal with any arbitrary calendar system.
The section below outlines how those assumptions can cause problems
The primary mechanism for reducing this increased risk of bugs is a strong code review process.
This should also be considered a extra cost in maintenance for the lifetime of the code.
2) This interface does not enforce immutability of implementations.
While the implementation notes indicate that all implementations must be immutable
there is nothing in the code or type system to enforce this. Any method declared
to accept a ChronoLocalDate could therefore be passed a poorly or
maliciously written mutable implementation.
3) Applications using this interface must consider the impact of eras.
LocalDate shields users from the concept of eras, by ensuring that getYear()
returns the proleptic year. That decision ensures that developers can think of
LocalDate instances as consisting of three fields - year, month-of-year and day-of-month.
By contrast, users of this interface must think of dates as consisting of four fields -
era, year-of-era, month-of-year and day-of-month. The extra era field is frequently
forgotten, yet it is of vital importance to dates in an arbitrary calendar system.
For example, in the Japanese calendar system, the era represents the reign of an Emperor.
Whenever one reign ends and another starts, the year-of-era is reset to one.
4) The only agreed international standard for passing a date between two systems is the ISO-8601 standard which requires the ISO calendar system. Using this interface throughout the application will inevitably lead to the requirement to pass the date across a network or component boundary, requiring an application specific protocol or format.
5) Long term persistence, such as a database, will almost always only accept dates in the ISO-8601 calendar system (or the related Julian-Gregorian). Passing around dates in other calendar systems increases the complications of interacting with persistence.
6) Most of the time, passing a ChronoLocalDate throughout an application
is unnecessary, as discussed in the last section below.
Code that queries the day-of-month and assumes that the value will never be more than 31 is invalid. Some calendar systems have more than 31 days in some months.
Code that adds 12 months to a date and assumes that a year has been added is invalid. Some calendar systems have a different number of months, such as 13 in the Coptic or Ethiopic.
Code that adds one month to a date and assumes that the month-of-year value will increase by one or wrap to the next year is invalid. Some calendar systems have a variable number of months in a year, such as the Hebrew.
Code that adds one month, then adds a second one month and assumes that the day-of-month will remain close to its original value is invalid. Some calendar systems have a large difference between the length of the longest month and the length of the shortest month. For example, the Coptic or Ethiopic have 12 months of 30 days and 1 month of 5 days.
Code that adds seven days and assumes that a week has been added is invalid. Some calendar systems have weeks of other than seven days, such as the French Revolutionary.
Code that assumes that because the year of date1 is greater than the year of date2
then date1 is after date2 is invalid. This is invalid for all calendar systems
when referring to the year-of-era, and especially untrue of the Japanese calendar system
where the year-of-era restarts with the reign of every new Emperor.
Code that treats month-of-year one and day-of-month one as the start of the year is invalid. Not all calendar systems start the year when the month value is one.
In general, manipulating a date, and even querying a date, is wide open to bugs when the calendar system is unknown at development time. This is why it is essential that code using this interface is subjected to additional code reviews. It is also why an architectural decision to avoid this interface type is usually the correct one.
LocalDate.
LocalDate to and from the user's preferred calendar system during
printing and parsing
As discussed above, performing calculations on a date where the rules of the calendar system are pluggable requires skill and is not recommended. Fortunately, the need to perform calculations on a date in an arbitrary calendar system is extremely rare. For example, it is highly unlikely that the business rules of a library book rental scheme will allow rentals to be for one month, where meaning of the month is dependent on the user's preferred calendar system.
A key use case for calculations on a date in an arbitrary calendar system is producing a month-by-month calendar for display and user interaction. Again, this is a UI issue, and use of this interface solely within a few methods of the UI layer may be justified.
In any other part of the system, where a date must be manipulated in a calendar system other than ISO, the use case will generally specify the calendar system to use. For example, an application may need to calculate the next Islamic or Hebrew holiday which may require manipulating the date. This kind of use case can be handled as follows:
LocalDate being passed to the method
LocalDate
TemporalAccessor if read-only access is required, or use Temporal
if read-write access is required.
Implementation Specification
This interface must be implemented with care to ensure other classes operate correctly. All implementations that can be instantiated must be final, immutable and thread-safe. Subclasses should be Serializable wherever possible.
Additional calendar systems may be added to the system.
See Chronology for more details.
| Modifier and Type | Method and Description |
|---|---|
| public default Temporal | Returns: the adjusted object, not nullthe target object to be adjusted, not null temporal)Implements java. Adjusts the specified temporal object to have the same date as this object. |
| public default ChronoLocalDateTime | |
| public default int | Returns: the comparator value, that is the comparison of this local date with theother local date and this chronology with the other chronology,
in order, returning the first non-zero result, and otherwise returning zerothe other date to compare to, not null other)Implements java. Compares this date to another date, including the chronology. |
| public boolean | |
| public default String | Returns: the formatted date string, not nullthe formatter to use, not null formatter)Formats this date using the specified formatter. |
| public static ChronoLocalDate | Returns: the date, not nullthe temporal object to convert, not null temporal)Obtains an instance of |
| public Chronology | |
| public default Era | Returns: the chronology specific era constant applicable at this date, not nullGets the era, as defined by the chronology. |
| public int | |
| public default boolean | Returns: true if this is after the specified datethe other date to compare to, not null other)Checks if this date is after the specified date ignoring the chronology. |
| public default boolean | Returns: true if this is before the specified datethe other date to compare to, not null other)Checks if this date is before the specified date ignoring the chronology. |
| public default boolean | Returns: true if the underlying date is equal to the specified datethe other date to compare to, not null other)Checks if this date is equal to the specified date ignoring the chronology. |
| public default boolean | Returns: true if this date is in a leap year, false otherwiseChecks if the year is a leap year, as defined by the calendar system. |
| public default boolean | Returns: true if the field can be queried, false if notthe field to check, null returns false field)Implements java. Checks if the specified field is supported. |
| public default boolean | Returns: true if the unit can be added/subtracted, false if notthe unit to check, null returns false unit)Implements java. Checks if the specified unit is supported. |
| public int | Returns: the length of the month in daysReturns the length of the month represented by this date, as defined by the calendar system. |
| public default int | Returns: the length of the year in daysReturns the length of the year represented by this date, as defined by the calendar system. |
| public default ChronoLocalDate | minus(TemporalAmount
the amount to subtract, not null amount)Overrides default java. Returns an object of the same type as this object with an amount subtracted. |
| public default ChronoLocalDate | minus(long
the amount of the specified unit to subtract, may be negative amountToSubtract, TemporalUnit the unit of the amount to subtract, not null unit)Overrides default java. Returns an object of the same type as this object with the specified period subtracted. |
| public default ChronoLocalDate | plus(TemporalAmount
the amount to add, not null amount)Overrides default java. Returns an object of the same type as this object with an amount added. |
| public default ChronoLocalDate | plus(long
the amount of the specified unit to add, may be negative amountToAdd, TemporalUnit the unit of the amount to add, not null unit)Implements java. Returns an object of the same type as this object with the specified period added. |
| public default < the type of the result R> R | Returns: the query result, null may be returned (defined by the query)the query to invoke, not null query)Overrides default java. Queries this date using the specified query. |
| public static Comparator | Returns: a comparator that compares in time-line order ignoring the chronologyGets a comparator that compares |
| public default long | |
| public String | |
| public long | Returns: the amount of time between this date and the end datethe end date, exclusive, which is converted to a
endExclusive, TemporalUnit ChronoLocalDate in the same chronology, not nullthe unit to measure the amount in, not null unit)Redeclares java. Calculates the amount of time until another date in terms of the specified unit. |
| public ChronoPeriod | Returns: the period between this date and the end date, not nullthe end date, exclusive, which may be in any chronology, not null endDateExclusive)Calculates the period between this date and another date as a |
| public default ChronoLocalDate | with(TemporalAdjuster
the adjuster to use, not null adjuster)Overrides default java. Returns an adjusted object of the same type as this object with the adjustment made. |
| public default ChronoLocalDate | with(TemporalField
the field to set in the result, not null field, long the new value of the field in the result newValue)Implements java. Returns an object of the same type as this object with the specified field altered. |
| adjustInto | back to summary |
|---|---|
| public default Temporal adjustInto(Temporal temporal) Implements java. Adjusts the specified temporal object to have the same date as this object. This returns a temporal object of the same observable type as the input with the date changed to be the same as this.
The adjustment is equivalent to using
In most cases, it is clearer to reverse the calling pattern by using
// these two lines are equivalent, but the second approach is recommended temporal = thisLocalDate.adjustInto(temporal); temporal = temporal.with(thisLocalDate); This instance is immutable and unaffected by this method call.
| |
| atTime | back to summary |
|---|---|
| public default ChronoLocalDateTime Combines this date with a time to create a
This returns a
| |
| compareTo | back to summary |
|---|---|
| public default int compareTo(ChronoLocalDate other) Implements java. Compares this date to another date, including the chronology.
The comparison is based first on the underlying time-line date, then
on the chronology.
It is "consistent with equals", as defined by For example, the following is the comparator order:
If all the date objects being compared are in the same chronology, then the
additional chronology stage is not required and only the local date is used.
To compare the dates of two This default implementation performs the comparison defined above.
| |
| equals | back to summary |
|---|---|
| public boolean equals(Object obj) Checks if this date is equal to another date, including the chronology. Compares this date with another ensuring that the date and chronology are the same.
To compare the dates of two | |
| format | back to summary |
|---|---|
| public default String format(DateTimeFormatter formatter) Formats this date using the specified formatter. This date will be passed to the formatter to produce a string. The default implementation must behave as follows: return formatter.format(this);
| |
| from | back to summary |
|---|---|
| public static ChronoLocalDate from(TemporalAccessor temporal) Obtains an instance of
This obtains a local date based on the specified temporal.
A
The conversion extracts and combines the chronology and the date
from the temporal object. The behavior is equivalent to using
This method matches the signature of the functional interface
| |
| getChronology | back to summary |
|---|---|
| public Chronology getChronology() Gets the chronology of this date.
The
| |
| getEra | back to summary |
|---|---|
| public default Era getEra() Gets the era, as defined by the chronology.
The era is, conceptually, the largest division of the time-line.
Most calendar systems have a single epoch dividing the time-line into two eras.
However, some have multiple eras, such as one for the reign of each leader.
The exact meaning is determined by the
All correctly implemented
This default implementation uses
| |
| hashCode | back to summary |
|---|---|
| public int hashCode() A hash code for this date.
| |
| isAfter | back to summary |
|---|---|
| public default boolean isAfter(ChronoLocalDate other) Checks if this date is after the specified date ignoring the chronology.
This method differs from the comparison in This default implementation performs the comparison based on the epoch-day.
| |
| isBefore | back to summary |
|---|---|
| public default boolean isBefore(ChronoLocalDate other) Checks if this date is before the specified date ignoring the chronology.
This method differs from the comparison in This default implementation performs the comparison based on the epoch-day.
| |
| isEqual | back to summary |
|---|---|
| public default boolean isEqual(ChronoLocalDate other) Checks if this date is equal to the specified date ignoring the chronology.
This method differs from the comparison in This default implementation performs the comparison based on the epoch-day.
| |
| isLeapYear | back to summary |
|---|---|
| public default boolean isLeapYear() Checks if the year is a leap year, as defined by the calendar system. A leap-year is a year of a longer length than normal. The exact meaning is determined by the chronology with the constraint that a leap-year must imply a year-length longer than a non leap-year.
This default implementation uses
| |
| isSupported | back to summary |
|---|---|
| public default boolean isSupported(TemporalField field) Implements java. Checks if the specified field is supported.
This checks if the specified field can be queried on this date.
If false, then calling the
The set of supported fields is defined by the chronology and normally includes
all
If the field is not a
| |
| isSupported | back to summary |
|---|---|
| public default boolean isSupported(TemporalUnit unit) Implements java. Checks if the specified unit is supported.
This checks if the specified unit can be added to or subtracted from this date.
If false, then calling the
The set of supported units is defined by the chronology and normally includes
all
If the unit is not a
| |
| lengthOfMonth | back to summary |
|---|---|
| public int lengthOfMonth() Returns the length of the month represented by this date, as defined by the calendar system. This returns the length of the month in days.
| |
| lengthOfYear | back to summary |
|---|---|
| public default int lengthOfYear() Returns the length of the year represented by this date, as defined by the calendar system. This returns the length of the year in days.
The default implementation uses
| |
| minus | back to summary |
|---|---|
| public default ChronoLocalDate minus(TemporalAmount amount) Overrides default java. Doc from java. Returns an object of the same type as this object with an amount subtracted.
This adjusts this temporal, subtracting according to the rules of the specified amount.
The amount is typically a Some example code indicating how and why this method is used: date = date.minus(period); // subtract a Period instance date = date.minus(duration); // subtract a Duration instance date = date.minus(workingDays(6)); // example user-written workingDays method
Note that calling
| |
| minus | back to summary |
|---|---|
| public default ChronoLocalDate minus(long amountToSubtract, TemporalUnit unit) Overrides default java. Doc from java. Returns an object of the same type as this object with the specified period subtracted.
This method returns a new object based on this one with the specified period subtracted.
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 March, then subtracting one month would be unclear. In cases like this, the field 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.
| |
| plus | back to summary |
|---|---|
| public default ChronoLocalDate plus(TemporalAmount amount) Overrides default java. Doc from java. Returns an object of the same type as this object with an amount added.
This adjusts this temporal, adding according to the rules of the specified amount.
The amount is typically a Some example code indicating how and why this method is used: date = date.plus(period); // add a Period instance date = date.plus(duration); // add a Duration instance date = date.plus(workingDays(6)); // example user-written workingDays method
Note that calling
| |
| plus | back to summary |
|---|---|
| public default ChronoLocalDate plus(long amountToAdd, TemporalUnit unit) Implements java. Doc from java. Returns an object of the same type as this object with the specified period added.
This method returns a new object based on this one with the specified period added.
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 adding one month would be unclear. In cases like this, the field 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.
| |
| query | back to summary |
|---|---|
| public default <R> R query(TemporalQuery<R> query) Overrides default java. Queries this date using the specified query.
This queries this date using the specified query strategy object.
The
The result of this method is obtained by invoking the
| |
| timeLineOrder | back to summary |
|---|---|
| public static Comparator Gets a comparator that compares
This comparator differs from the comparison in
| |
| toEpochDay | back to summary |
|---|---|
| public default long toEpochDay() Converts this date to the Epoch Day.
The
This default implementation queries the
| |
| toString | back to summary |
|---|---|
| public String toString() Outputs this date as a The output will include the full local date. | |
| until | back to summary |
|---|---|
| public long until(Temporal endExclusive, TemporalUnit unit) Redeclares java. Calculates the amount of time until another date in terms of the specified unit.
This calculates the amount of time between two
There are two equivalent ways of using this method.
The first is to invoke this method.
The second is to use // these two lines are equivalent amount = start.until(end, MONTHS); amount = MONTHS.between(start, end);The choice should be made based on which makes the code more readable.
The calculation is implemented in this method for
If the unit is not a This instance is immutable and unaffected by this method call.
| |
| until | back to summary |
|---|---|
| public ChronoPeriod until(ChronoLocalDate endDateExclusive) Calculates the period between this date and another date as a
This calculates the period between two dates. All supplied chronologies
calculate the period using years, months and days, however the
The start and end points are The calculation is performed using the chronology of this date. If necessary, the input date will be converted to match. This instance is immutable and unaffected by this method call.
| |
| with | back to summary |
|---|---|
| public default ChronoLocalDate with(TemporalAdjuster adjuster) Overrides default java. Doc from java. Returns an adjusted object of the same type as this object with the adjustment made.
This adjusts this date-time according to the rules of the specified adjuster.
A simple adjuster might simply set the one of the fields, such as the year field.
A more complex adjuster might set the date to the last day of the month.
A selection of common adjustments is provided in
Some example code indicating how and why this method is used: date = date.with(Month.JULY); // most key classes implement TemporalAdjuster date = date.with(lastDayOfMonth()); // static import from Adjusters date = date.with(next(WEDNESDAY)); // static import from Adjusters and DayOfWeek
| |
| with | back to summary |
|---|---|
| public default ChronoLocalDate with(TemporalField field, long newValue) Implements java. Doc from java. Returns an object of the same type as this object with the specified field altered.
This returns a new object based on this one with the value for the specified 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 field 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.
| |