+ * Most applications should declare method signatures, fields and variables + * as {@link LocalDate}, not this interface. + *
+ * A {@code ChronoLocalDate} is the abstract representation of a date where the + * {@code Chronology chronology}, or calendar system, is pluggable. + * The date is defined in terms of fields expressed by {@link TemporalField}, + * where most common implementations are defined in {@link ChronoField}. + * The chronology defines how the calendar system operates and the meaning of + * the standard fields. + * + *
+ * The primary use case where this interface should be used is where the generic
+ * type parameter {@code
+ * When the chronology is defined in the generic type parameter as ? or otherwise
+ * unknown at development time, the rest of the discussion below applies.
+ *
+ * To emphasize the point, declaring a method signature, field or variable as this
+ * interface type can initially seem like the sensible way to globalize an application,
+ * however it is usually the wrong approach.
+ * As such, it should be considered an application-wide architectural decision to choose
+ * to use this interface as opposed to {@code LocalDate}.
+ *
+ *
+ * 1) Applications using this interface, as opposed to using just {@code 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 {@code ChronoLocalDate} could therefore be passed a poorly or
+ * maliciously written mutable implementation.
+ *
+ * 3) Applications using this interface must consider the impact of eras.
+ * {@code LocalDate} shields users from the concept of eras, by ensuring that {@code getYear()}
+ * returns the proleptic year. That decision ensures that developers can think of
+ * {@code 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 {@code 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 {@code date1} is greater than the year of {@code date2}
+ * then {@code date1} is after {@code 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.
+ *
+ *
+ * This approach treats the problem of globalized calendar systems as a localization issue
+ * and confines it to the UI layer. This approach is in keeping with other localization
+ * issues in the java platform.
+ *
+ * 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:
+ *
+ * Developers writing low-level frameworks or libraries should also avoid this interface.
+ * Instead, one of the two general purpose access interfaces should be used.
+ * Use {@link TemporalAccessor} if read-only access is required, or use {@link Temporal}
+ * if read-write access is required.
+ *
+ *
+ * Additional calendar systems may be added to the system.
+ * See {@link Chronology} for more details.
+ *
+ * @param
+ * This comparator differs from the comparison in {@link #compareTo} in that it
+ * only compares the underlying date and not the chronology.
+ * This allows dates in different calendar systems to be compared based
+ * on the time-line position.
+ * This is equivalent to using {@code Long.compare(date1.toEpochDay(), date2.toEpochDay())}.
+ *
+ * @see #isAfter
+ * @see #isBefore
+ * @see #isEqual
+ */
+ public static final Comparator
+ * The {@code Chronology} represents the calendar system in use.
+ * The era and other fields in {@link ChronoField} are defined by the chronology.
+ *
+ * @return the chronology, not null
+ */
+ Chronology getChronology();
+
+ /**
+ * 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 {@code Chronology}.
+ *
+ * All correctly implemented {@code Era} classes are singletons, thus it
+ * is valid code to write {@code date.getEra() == SomeChrono.ERA_NAME)}.
+ *
+ * This default implementation uses {@link Chronology#eraOf(int)}.
+ *
+ * @return the chronology specific era constant applicable at this date, not null
+ */
+ public default Era getEra() {
+ return getChronology().eraOf(get(ERA));
+ }
+
+ /**
+ * 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 {@link Chronology#isLeapYear(long)}.
+ *
+ * @return true if this date is in a leap year, false otherwise
+ */
+ public default boolean isLeapYear() {
+ return getChronology().isLeapYear(getLong(YEAR));
+ }
+
+ /**
+ * 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.
+ *
+ * @return the length of the month in days
+ */
+ int lengthOfMonth();
+
+ /**
+ * 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 {@link #isLeapYear()} and returns 365 or 366.
+ *
+ * @return the length of the year in days
+ */
+ public default int lengthOfYear() {
+ return (isLeapYear() ? 366 : 365);
+ }
+
+ @Override
+ public default boolean isSupported(TemporalField field) {
+ if (field instanceof ChronoField) {
+ return ((ChronoField) field).isDateField();
+ }
+ return field != null && field.isSupportedBy(this);
+ }
+
+ //-----------------------------------------------------------------------
+ // override for covariant return type
+ /**
+ * {@inheritDoc}
+ * @throws DateTimeException {@inheritDoc}
+ * @throws ArithmeticException {@inheritDoc}
+ */
+ @Override
+ public default D with(TemporalAdjuster adjuster) {
+ return (D) getChronology().ensureChronoLocalDate(Temporal.super.with(adjuster));
+ }
+
+ /**
+ * {@inheritDoc}
+ * @throws DateTimeException {@inheritDoc}
+ * @throws ArithmeticException {@inheritDoc}
+ */
+ @Override
+ public default D with(TemporalField field, long newValue) {
+ if (field instanceof ChronoField) {
+ throw new DateTimeException("Unsupported field: " + field.getName());
+ }
+ return (D) getChronology().ensureChronoLocalDate(field.adjustInto(this, newValue));
+ }
+
+ /**
+ * {@inheritDoc}
+ * @throws DateTimeException {@inheritDoc}
+ * @throws ArithmeticException {@inheritDoc}
+ */
+ @Override
+ public default D plus(TemporalAmount amount) {
+ return (D) getChronology().ensureChronoLocalDate(Temporal.super.plus(amount));
+ }
+
+ /**
+ * {@inheritDoc}
+ * @throws DateTimeException {@inheritDoc}
+ * @throws ArithmeticException {@inheritDoc}
+ */
+ @Override
+ public default D plus(long amountToAdd, TemporalUnit unit) {
+ if (unit instanceof ChronoUnit) {
+ throw new DateTimeException("Unsupported unit: " + unit.getName());
+ }
+ return (D) getChronology().ensureChronoLocalDate(unit.addTo(this, amountToAdd));
+ }
+
+ /**
+ * {@inheritDoc}
+ * @throws DateTimeException {@inheritDoc}
+ * @throws ArithmeticException {@inheritDoc}
+ */
+ @Override
+ public default D minus(TemporalAmount amount) {
+ return (D) getChronology().ensureChronoLocalDate(Temporal.super.minus(amount));
+ }
+
+ /**
+ * {@inheritDoc}
+ * @throws DateTimeException {@inheritDoc}
+ * @throws ArithmeticException {@inheritDoc}
+ */
+ @Override
+ public default D minus(long amountToSubtract, TemporalUnit unit) {
+ return (D) getChronology().ensureChronoLocalDate(Temporal.super.minus(amountToSubtract, unit));
+ }
+
+ //-----------------------------------------------------------------------
+ /**
+ * Queries this date using the specified query.
+ *
+ * This queries this date using the specified query strategy object.
+ * The {@code TemporalQuery} object defines the logic to be used to
+ * obtain the result. Read the documentation of the query to understand
+ * what the result of this method will be.
+ *
+ * The result of this method is obtained by invoking the
+ * {@link TemporalQuery#queryFrom(TemporalAccessor)} method on the
+ * specified query passing {@code this} as the argument.
+ *
+ * @param
+ * 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 {@link Temporal#with(TemporalField, long)}
+ * passing {@link ChronoField#EPOCH_DAY} as the field.
+ *
+ * In most cases, it is clearer to reverse the calling pattern by using
+ * {@link Temporal#with(TemporalAdjuster)}:
+ *
+ * This instance is immutable and unaffected by this method call.
+ *
+ * @param temporal the target object to be adjusted, not null
+ * @return the adjusted object, not null
+ * @throws DateTimeException if unable to make the adjustment
+ * @throws ArithmeticException if numeric overflow occurs
+ */
+ @Override
+ public default Temporal adjustInto(Temporal temporal) {
+ return temporal.with(EPOCH_DAY, toEpochDay());
+ }
+
+ /**
+ * Calculates the period between this date and another date in
+ * terms of the specified unit.
+ *
+ * This calculates the period between two dates in terms of a single unit.
+ * The start and end points are {@code this} and the specified date.
+ * The result will be negative if the end is before the start.
+ * The {@code Temporal} passed to this method must be a
+ * {@code ChronoLocalDate} in the same chronology.
+ * The calculation returns a whole number, representing the number of
+ * complete units between the two dates.
+ * For example, the period in days between two dates can be calculated
+ * using {@code startDate.periodUntil(endDate, DAYS)}.
+ *
+ * There are two equivalent ways of using this method.
+ * The first is to invoke this method.
+ * The second is to use {@link TemporalUnit#between(Temporal, Temporal)}:
+ *
+ * The calculation is implemented in this method for {@link ChronoUnit}.
+ * The units {@code DAYS}, {@code WEEKS}, {@code MONTHS}, {@code YEARS},
+ * {@code DECADES}, {@code CENTURIES}, {@code MILLENNIA} and {@code ERAS}
+ * should be supported by all implementations.
+ * Other {@code ChronoUnit} values will throw an exception.
+ *
+ * If the unit is not a {@code ChronoUnit}, then the result of this method
+ * is obtained by invoking {@code TemporalUnit.between(Temporal, Temporal)}
+ * passing {@code this} as the first argument and the input temporal as
+ * the second argument.
+ *
+ * This instance is immutable and unaffected by this method call.
+ *
+ * @param endDate the end date, which must be a {@code ChronoLocalDate}
+ * in the same chronology, not null
+ * @param unit the unit to measure the period in, not null
+ * @return the amount of the period between this date and the end date
+ * @throws DateTimeException if the period cannot be calculated
+ * @throws ArithmeticException if numeric overflow occurs
+ */
+ @Override // override for Javadoc
+ public abstract long periodUntil(Temporal endDate, TemporalUnit unit);
+
+ /**
+ * Calculates the period between this date and another date as a {@code Period}.
+ *
+ * This calculates the period between two dates in terms of years, months and days.
+ * The start and end points are {@code this} and the specified date.
+ * The result will be negative if the end is before the start.
+ *
+ * The calculation is performed using the the chronology of this date.
+ * If necessary, the input date will be converted to match.
+ *
+ * The result of this method can be a negative period if the end is before the start.
+ * The negative sign will be the same in each of year, month and day.
+ *
+ * This instance is immutable and unaffected by this method call.
+ *
+ * @param endDate the end date, exclusive, which may be in any chronology, not null
+ * @return the period between this date and the end date, not null
+ * @throws DateTimeException if the period cannot be calculated
+ * @throws ArithmeticException if numeric overflow occurs
+ */
+ public abstract Period periodUntil(ChronoLocalDate endDate);
+
+ //-----------------------------------------------------------------------
+ /**
+ * Combines this date with a time to create a {@code ChronoLocalDateTime}.
+ *
+ * This returns a {@code ChronoLocalDateTime} formed from this date at the specified time.
+ * All possible combinations of date and time are valid.
+ *
+ * @param localTime the local time to use, not null
+ * @return the local date-time formed from this date and the specified time, not null
+ */
+ public default ChronoLocalDateTime
+ * The {@link ChronoField#EPOCH_DAY Epoch Day count} is a simple
+ * incrementing count of days where day 0 is 1970-01-01 (ISO).
+ * This definition is the same for all chronologies, enabling conversion.
+ *
+ * This default implementation queries the {@code EPOCH_DAY} field.
+ *
+ * @return the Epoch Day equivalent to this date
+ */
+ public default long toEpochDay() {
+ return getLong(EPOCH_DAY);
+ }
+
+ //-----------------------------------------------------------------------
+ /**
+ * 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 {@link Comparable}.
+ *
+ * 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 {@code TemporalAccessor} instances, including dates
+ * in two different chronologies, use {@link ChronoField#EPOCH_DAY} as a comparator.
+ *
+ * This default implementation performs the comparison defined above.
+ *
+ * @param other the other date to compare to, not null
+ * @return the comparator value, negative if less, positive if greater
+ */
+ @Override
+ public default int compareTo(ChronoLocalDate other) {
+ int cmp = Long.compare(toEpochDay(), other.toEpochDay());
+ if (cmp == 0) {
+ cmp = getChronology().compareTo(other.getChronology());
+ }
+ return cmp;
+ }
+
+ /**
+ * Checks if this date is after the specified date ignoring the chronology.
+ *
+ * This method differs from the comparison in {@link #compareTo} in that it
+ * only compares the underlying date and not the chronology.
+ * This allows dates in different calendar systems to be compared based
+ * on the time-line position.
+ * This is equivalent to using {@code date1.toEpochDay() > date2.toEpochDay()}.
+ *
+ * This default implementation performs the comparison based on the epoch-day.
+ *
+ * @param other the other date to compare to, not null
+ * @return true if this is after the specified date
+ */
+ public default boolean isAfter(ChronoLocalDate other) {
+ return this.toEpochDay() > other.toEpochDay();
+ }
+
+ /**
+ * Checks if this date is before the specified date ignoring the chronology.
+ *
+ * This method differs from the comparison in {@link #compareTo} in that it
+ * only compares the underlying date and not the chronology.
+ * This allows dates in different calendar systems to be compared based
+ * on the time-line position.
+ * This is equivalent to using {@code date1.toEpochDay() < date2.toEpochDay()}.
+ *
+ * This default implementation performs the comparison based on the epoch-day.
+ *
+ * @param other the other date to compare to, not null
+ * @return true if this is before the specified date
+ */
+ public default boolean isBefore(ChronoLocalDate other) {
+ return this.toEpochDay() < other.toEpochDay();
+ }
+
+ /**
+ * Checks if this date is equal to the specified date ignoring the chronology.
+ *
+ * This method differs from the comparison in {@link #compareTo} in that it
+ * only compares the underlying date and not the chronology.
+ * This allows dates in different calendar systems to be compared based
+ * on the time-line position.
+ * This is equivalent to using {@code date1.toEpochDay() == date2.toEpochDay()}.
+ *
+ * This default implementation performs the comparison based on the epoch-day.
+ *
+ * @param other the other date to compare to, not null
+ * @return true if the underlying date is equal to the specified date
+ */
+ public default boolean isEqual(ChronoLocalDate other) {
+ return this.toEpochDay() == other.toEpochDay();
+ }
+
+ //-----------------------------------------------------------------------
+ /**
+ * 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 {@code TemporalAccessor} instances, including dates
+ * in two different chronologies, use {@link ChronoField#EPOCH_DAY} as a comparator.
+ *
+ * @param obj the object to check, null returns false
+ * @return true if this is equal to the other date
+ */
+ @Override
+ boolean equals(Object obj);
+
+ /**
+ * A hash code for this date.
+ *
+ * @return a suitable hash code
+ */
+ @Override
+ int hashCode();
+
+ //-----------------------------------------------------------------------
+ /**
+ * Outputs this date as a {@code String}.
+ *
+ * The output will include the full local date and the chronology ID.
+ *
+ * @return the formatted date, not null
+ */
+ @Override
+ String toString();
+
+ /**
+ * Outputs this date as a {@code String} using the formatter.
+ *
+ * The default implementation must behave as follows:
+ * Architectural issues to consider
+ * These are some of the points that must be considered before using this interface
+ * throughout an application.
+ * False assumptions causing bugs in multi-calendar system code
+ * As indicated above, there are many issues to consider when try to use and manipulate a
+ * date in an arbitrary calendar system. These are some of the key issues.
+ * Using LocalDate instead
+ * The primary alternative to using this interface throughout your application is as follows.
+ *
+ *
+ *
Specification for implementors
+ * 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.
+ *
+ * // these two lines are equivalent, but the second approach is recommended
+ * temporal = thisLocalDate.adjustInto(temporal);
+ * temporal = temporal.with(thisLocalDate);
+ *
+ *
+ * // these two lines are equivalent
+ * amount = start.periodUntil(end, MONTHS);
+ * amount = MONTHS.between(start, end);
+ *
+ * The choice should be made based on which makes the code more readable.
+ *
+ *
+ * Values #2 and #3 represent the same date on the time-line.
+ * When two values represent the same date, the chronology ID is compared to distinguish them.
+ * This step is needed to make the ordering "consistent with equals".
+ *
+ * return formatter.format(this);
+ *
+ *
+ * @param formatter the formatter to use, not null
+ * @return the formatted date string, not null
+ * @throws DateTimeException if an error occurs during printing
+ */
+ public default String toString(DateTimeFormatter formatter) {
+ Objects.requireNonNull(formatter, "formatter");
+ return formatter.format(this);
+ }
+
+}