This queries this date-time using the specified query strategy object.
Queries are a key tool for extracting information from date-times. They exists to externalize the process of querying, permitting different approaches, as per the strategy design pattern. Examples might be a query that checks if the date is the day before February 29th in a leap year, or calculates the number of days to your next birthday.
The most common query implementations are method references, such as {@code LocalDate::from} and {@code ZoneId::from}. Additional implementations are provided as static methods on {@link TemporalQuery}. @implSpec The default implementation must behave equivalent to this code:
if (query == TemporalQueries.zoneId() || query == TemporalQueries.chronology() || query == TemporalQueries.precision()) { return null; } return query.queryFrom(this); Future versions are permitted to add further queries to the if statement. All classes implementing this interface and overriding this method must call {@code TemporalAccessor.super.query(query)}. JDK classes may avoid calling super if they provide behavior equivalent to the default behaviour, however non-JDK classes may not utilize this optimization and must call {@code super}.
If the implementation can supply a value for one of the queries listed in the if statement of the default implementation, then it must do so. For example, an application-defined {@code HourMin} class storing the hourand minute must override this method as follows:
if (query == TemporalQueries.precision()) { return MINUTES; } return TemporalAccessor.super.query(query); Implementations must ensure that no observable state is altered when this read-only method is invoked. @param < R> 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 @throws ArithmeticException if numeric overflow occurs
| |
| |