/* * Copyright (c) 2012, 2015, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. Oracle designates this * particular file as subject to the "Classpath" exception as provided * by Oracle in the LICENSE file that accompanied this code. * * This code is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * version 2 for more details (a copy is included in the LICENSE file that * accompanied this code). * * You should have received a copy of the GNU General Public License version * 2 along with this work; if not, write to the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. * * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA * or visit www.oracle.com if you need additional information or have any * questions. */ /* * This file is available under and governed by the GNU General Public * License version 2 only, as published by the Free Software Foundation. * However, the following notice accompanied the original version of this * file: * * Copyright (c) 2012, Stephen Colebourne & Michael Nascimento Santos * * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions are met: * * * Redistributions of source code must retain the above copyright notice, * this list of conditions and the following disclaimer. * * * Redistributions in binary form must reproduce the above copyright notice, * this list of conditions and the following disclaimer in the documentation * and/or other materials provided with the distribution. * * * Neither the name of JSR-310 nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ package java.time.chrono; import static java.time.temporal.ChronoField.EPOCH_DAY; import static java.time.temporal.ChronoField.ERA; import static java.time.temporal.ChronoField.YEAR; import static java.time.temporal.ChronoUnit.DAYS; import java.time.DateTimeException; import java.time.LocalDate; import java.time.LocalTime; import java.time.format.DateTimeFormatter; import java.time.temporal.ChronoField; import java.time.temporal.ChronoUnit; import java.time.temporal.Temporal; import java.time.temporal.TemporalAccessor; import java.time.temporal.TemporalAdjuster; import java.time.temporal.TemporalAmount; import java.time.temporal.TemporalField; import java.time.temporal.TemporalQueries; import java.time.temporal.TemporalQuery; import java.time.temporal.TemporalUnit; import java.time.temporal.UnsupportedTemporalTypeException; import java.util.Comparator; import java.util.Objects; /** * A date without time-of-day or time-zone in an arbitrary chronology, intended * for advanced globalization use cases. *

* 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. * *

When to use this interface

* The design of the API encourages the use of {@code 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 {@code LocalDate}. * *

Architectural issues to consider

* These are some of the points that must be considered before using this interface * throughout an application. *

* 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. * *

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. *

* 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. * *

Using LocalDate instead

* The primary alternative to using this interface throughout your application is as follows. * * 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. * * @implSpec * 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 {@link Chronology} for more details. * * @since 1.8 */ public interface ChronoLocalDate extends Temporal, TemporalAdjuster, Comparable { /** * Gets a comparator that compares {@code ChronoLocalDate} in * time-line order ignoring the chronology. *

* 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 position of the date on the local time-line. * The underlying comparison is equivalent to comparing the epoch-day. * * @return a comparator that compares in time-line order ignoring the chronology * @see #isAfter * @see #isBefore * @see #isEqual */ static Comparator timeLineOrder() { return AbstractChronology.DATE_ORDER; } //----------------------------------------------------------------------- /** * Obtains an instance of {@code ChronoLocalDate} from a temporal object. *

* This obtains a local date based on the specified temporal. * A {@code TemporalAccessor} represents an arbitrary set of date and time information, * which this factory converts to an instance of {@code ChronoLocalDate}. *

* The conversion extracts and combines the chronology and the date * from the temporal object. The behavior is equivalent to using * {@link Chronology#date(TemporalAccessor)} with the extracted chronology. * Implementations are permitted to perform optimizations such as accessing * those fields that are equivalent to the relevant objects. *

* This method matches the signature of the functional interface {@link TemporalQuery} * allowing it to be used as a query via method reference, {@code ChronoLocalDate::from}. * * @param temporal the temporal object to convert, not null * @return the date, not null * @throws DateTimeException if unable to convert to a {@code ChronoLocalDate} * @see Chronology#date(TemporalAccessor) */ static ChronoLocalDate from(TemporalAccessor temporal) { if (temporal instanceof ChronoLocalDate) { return (ChronoLocalDate) temporal; } Objects.requireNonNull(temporal, "temporal"); Chronology chrono = temporal.query(TemporalQueries.chronology()); if (chrono == null) { throw new DateTimeException("Unable to obtain ChronoLocalDate from TemporalAccessor: " + temporal.getClass()); } return chrono.date(temporal); } //----------------------------------------------------------------------- /** * Gets the chronology of this date. *

* 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 */ 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 */ 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 */ default int lengthOfYear() { return (isLeapYear() ? 366 : 365); } /** * Checks if the specified field is supported. *

* This checks if the specified field can be queried on this date. * If false, then calling the {@link #range(TemporalField) range}, * {@link #get(TemporalField) get} and {@link #with(TemporalField, long)} * methods will throw an exception. *

* The set of supported fields is defined by the chronology and normally includes * all {@code ChronoField} date fields. *

* If the field is not a {@code ChronoField}, then the result of this method * is obtained by invoking {@code TemporalField.isSupportedBy(TemporalAccessor)} * passing {@code this} as the argument. * Whether the field is supported is determined by the field. * * @param field the field to check, null returns false * @return true if the field can be queried, false if not */ @Override default boolean isSupported(TemporalField field) { if (field instanceof ChronoField) { return field.isDateBased(); } return field != null && field.isSupportedBy(this); } /** * 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 {@link #plus(long, TemporalUnit)} and * {@link #minus(long, TemporalUnit) minus} methods will throw an exception. *

* The set of supported units is defined by the chronology and normally includes * all {@code ChronoUnit} date units except {@code FOREVER}. *

* If the unit is not a {@code ChronoUnit}, then the result of this method * is obtained by invoking {@code TemporalUnit.isSupportedBy(Temporal)} * passing {@code this} as the argument. * Whether the unit is supported is determined by the unit. * * @param unit the unit to check, null returns false * @return true if the unit can be added/subtracted, false if not */ @Override default boolean isSupported(TemporalUnit unit) { if (unit instanceof ChronoUnit) { return unit.isDateBased(); } return unit != null && unit.isSupportedBy(this); } //----------------------------------------------------------------------- // override for covariant return type /** * {@inheritDoc} * @throws DateTimeException {@inheritDoc} * @throws ArithmeticException {@inheritDoc} */ @Override default ChronoLocalDate with(TemporalAdjuster adjuster) { return ChronoLocalDateImpl.ensureValid(getChronology(), Temporal.super.with(adjuster)); } /** * {@inheritDoc} * @throws DateTimeException {@inheritDoc} * @throws UnsupportedTemporalTypeException {@inheritDoc} * @throws ArithmeticException {@inheritDoc} */ @Override default ChronoLocalDate with(TemporalField field, long newValue) { if (field instanceof ChronoField) { throw new UnsupportedTemporalTypeException("Unsupported field: " + field); } return ChronoLocalDateImpl.ensureValid(getChronology(), field.adjustInto(this, newValue)); } /** * {@inheritDoc} * @throws DateTimeException {@inheritDoc} * @throws ArithmeticException {@inheritDoc} */ @Override default ChronoLocalDate plus(TemporalAmount amount) { return ChronoLocalDateImpl.ensureValid(getChronology(), Temporal.super.plus(amount)); } /** * {@inheritDoc} * @throws DateTimeException {@inheritDoc} * @throws ArithmeticException {@inheritDoc} */ @Override default ChronoLocalDate plus(long amountToAdd, TemporalUnit unit) { if (unit instanceof ChronoUnit) { throw new UnsupportedTemporalTypeException("Unsupported unit: " + unit); } return ChronoLocalDateImpl.ensureValid(getChronology(), unit.addTo(this, amountToAdd)); } /** * {@inheritDoc} * @throws DateTimeException {@inheritDoc} * @throws ArithmeticException {@inheritDoc} */ @Override default ChronoLocalDate minus(TemporalAmount amount) { return ChronoLocalDateImpl.ensureValid(getChronology(), Temporal.super.minus(amount)); } /** * {@inheritDoc} * @throws DateTimeException {@inheritDoc} * @throws UnsupportedTemporalTypeException {@inheritDoc} * @throws ArithmeticException {@inheritDoc} */ @Override default ChronoLocalDate minus(long amountToSubtract, TemporalUnit unit) { return ChronoLocalDateImpl.ensureValid(getChronology(), 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 the type of the result * @param query the query to invoke, not null * @return the query result, null may be returned (defined by the query) * @throws DateTimeException if unable to query (defined by the query) * @throws ArithmeticException if numeric overflow occurs (defined by the query) */ @SuppressWarnings("unchecked") @Override default R query(TemporalQuery query) { if (query == TemporalQueries.zoneId() || query == TemporalQueries.zone() || query == TemporalQueries.offset()) { return null; } else if (query == TemporalQueries.localTime()) { return null; } else if (query == TemporalQueries.chronology()) { return (R) getChronology(); } else if (query == TemporalQueries.precision()) { return (R) DAYS; } // inline TemporalAccessor.super.query(query) as an optimization // non-JDK classes are not permitted to make this optimization return query.queryFrom(this); } /** * 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 {@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)}: *

     *   // 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. * * @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 default Temporal adjustInto(Temporal temporal) { return temporal.with(EPOCH_DAY, toEpochDay()); } /** * Calculates the amount of time until another date in terms of the specified unit. *

* This calculates the amount of time between two {@code ChronoLocalDate} * objects in terms of a single {@code TemporalUnit}. * 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 is converted to a * {@code ChronoLocalDate} using {@link Chronology#date(TemporalAccessor)}. * The calculation returns a whole number, representing the number of * complete units between the two dates. * For example, the amount in days between two dates can be calculated * using {@code startDate.until(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)}: *

     *   // 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 {@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 converted input temporal as * the second argument. *

* This instance is immutable and unaffected by this method call. * * @param endExclusive the end date, exclusive, which is converted to a * {@code ChronoLocalDate} in the same chronology, not null * @param unit the unit to measure the amount in, not null * @return the amount of time between this date and the end date * @throws DateTimeException if the amount cannot be calculated, or the end * temporal cannot be converted to a {@code ChronoLocalDate} * @throws UnsupportedTemporalTypeException if the unit is not supported * @throws ArithmeticException if numeric overflow occurs */ @Override // override for Javadoc long until(Temporal endExclusive, TemporalUnit unit); /** * Calculates the period between this date and another date as a {@code ChronoPeriod}. *

* This calculates the period between two dates. All supplied chronologies * calculate the period using years, months and days, however the * {@code ChronoPeriod} API allows the period to be represented using other units. *

* 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 negative sign will be the same in each of year, month and day. *

* 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. * * @param endDateExclusive 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 */ ChronoPeriod until(ChronoLocalDate endDateExclusive); /** * 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);
     * 
* * @param formatter the formatter to use, not null * @return the formatted date string, not null * @throws DateTimeException if an error occurs during printing */ default String format(DateTimeFormatter formatter) { Objects.requireNonNull(formatter, "formatter"); return formatter.format(this); } //----------------------------------------------------------------------- /** * 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 */ @SuppressWarnings("unchecked") default ChronoLocalDateTime atTime(LocalTime localTime) { return ChronoLocalDateTimeImpl.of(this, localTime); } //----------------------------------------------------------------------- /** * Converts this date to the Epoch Day. *

* 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 */ 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: *

    *
  1. {@code 2012-12-03 (ISO)}
  2. *
  3. {@code 2012-12-04 (ISO)}
  4. *
  5. {@code 2555-12-04 (ThaiBuddhist)}
  6. *
  7. {@code 2012-12-05 (ISO)}
  8. *
* 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". *

* 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 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 */ 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 */ 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 */ 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. * * @return the formatted date, not null */ @Override String toString(); }