Fix inconsistent roundup behavior for date ranges using Temporal object as terms

`roundUp` works well for terms that contain date math expressions.
Otherwise, if falling through to using roundUp parsers, the behavior can
be surprising. Instead, these parsers fill missing date components with
the max possible value, e.g. `2099-12` becomes
`2099-12-01T23:59:59.999_999_999Z`.

Prior to switching to Java time, Joda's LocalTime#toString()
consistently formatted time using `HH:mm:ss.SSS`. Without and missing
component, roundUp parsers behave just like normal parsers.

Java's LocalTime, however, outputs the shortest possible representation
and might omit seconds, milliseconds, etc.
This interferes badly with the behavior of the roundup parser. And as a
result of this, depending on the term, the lower bound could end up
larger than the upper bound, e.g. `1970-01-06T09:49Z`
becomes `1970-01-06T09:49:59.999Z`.

This PR disables roundUp parsers if the lower/upper term is a Temporal
object to restore the behavior prior to switching to Java time.

Author: mosche

server/src/main/java/org/elasticsearch/index/mapper/RangeType.java

@@ -37,11 +37,13 @@
 import java.time.ZoneId;
 import java.time.ZoneOffset;
 import java.time.ZonedDateTime;
+import java.time.temporal.Temporal;
 import java.util.ArrayList;
 import java.util.Arrays;
 import java.util.List;
 import java.util.Set;
 import java.util.function.BiFunction;
+import java.util.function.LongSupplier;
 
 /** Enum defining the type of range */
 public enum RangeType {
@@ -293,28 +295,22 @@ public Query rangeQuery(
 
             DateMathParser dateMathParser = (parser == null) ? DateFieldMapper.DEFAULT_DATE_TIME_FORMATTER.toDateMathParser() : parser;
             boolean roundUp = includeLower == false; // using "gt" should round lower bound up
-            Long low = lowerTerm == null
-                ? minValue()
-                : dateMathParser.parse(
-                    lowerTerm instanceof BytesRef ? ((BytesRef) lowerTerm).utf8ToString() : lowerTerm.toString(),
-                    context::nowInMillis,
-                    roundUp,
-                    zone
-                ).toEpochMilli();
+            Long low = lowerTerm == null ? minValue() : parseRangeTerm(dateMathParser, lowerTerm, zone, roundUp, context::nowInMillis);
 
             roundUp = includeUpper; // using "lte" should round upper bound up
-            Long high = upperTerm == null
-                ? maxValue()
-                : dateMathParser.parse(
-                    upperTerm instanceof BytesRef ? ((BytesRef) upperTerm).utf8ToString() : upperTerm.toString(),
-                    context::nowInMillis,
-                    roundUp,
-                    zone
-                ).toEpochMilli();
-
+            Long high = upperTerm == null ? maxValue() : parseRangeTerm(dateMathParser, upperTerm, zone, roundUp, context::nowInMillis);
             return createRangeQuery(field, hasDocValues, low, high, includeLower, includeUpper, relation);
         }
 
+        private static long parseRangeTerm(DateMathParser parser, Object term, ZoneId zone, boolean roundUp, LongSupplier nowInMillis) {
+            String termString = term instanceof BytesRef ? ((BytesRef) term).utf8ToString() : term.toString();
+            // `roundUp` may only be used if the term is not a Temporal object. LocalTime#toString() and similar will output
+            // the shortest possible representation and might omit seconds, milliseconds, etc.
+            // That interferes badly with the behavior of the roundup parser leading to unexpected results.
+            boolean mayRoundUp = (term instanceof Temporal) == false;
+            return parser.parse(termString, nowInMillis, roundUp && mayRoundUp, zone).toEpochMilli();
+        }
+
         @Override
         public Query withinQuery(String field, Object from, Object to, boolean includeLower, boolean includeUpper) {
             return LONG.withinQuery(field, from, to, includeLower, includeUpper);

server/src/test/java/org/elasticsearch/index/mapper/RangeFieldTypeTests.java

@@ -89,7 +89,6 @@ public void testRangeQuery() throws Exception {
     /**
      * test the queries are correct if from/to are adjacent and the range is exclusive of those values
      */
-    @AwaitsFix(bugUrl = "https://github.com/elastic/elasticsearch/issues/86284")
     public void testRangeQueryIntersectsAdjacentValues() throws Exception {
         SearchExecutionContext context = createContext();
         ShapeRelation relation = randomFrom(ShapeRelation.values());
@@ -143,7 +142,6 @@ public void testRangeQueryIntersectsAdjacentValues() throws Exception {
     /**
      * check that we catch cases where the user specifies larger "from" than "to" value, not counting the include upper/lower settings
      */
-    @AwaitsFix(bugUrl = "https://github.com/elastic/elasticsearch/issues/86284")
     public void testFromLargerToErrors() throws Exception {
         SearchExecutionContext context = createContext();
         RangeFieldType ft = createDefaultFieldType();