Address review: spell out the accepted start_time and end_time literals

@penghuo on #5766: what are the supported literals -- the doc should be clear on it.

Replaced the prose list with a table, one row per form, each with examples. Testing every
candidate against a cluster rather than reading it off the format string turned up two
things the prose had wrong.

`yyyy-MM-dd HH:mm:ss` without milliseconds did not parse, only the `.SSS` form did. PPL
accepts that exact literal in a `where` clause, so a client mirroring its own filter into
these parameters would have got silent non-pruning. Added to the accepted formats, with
the date-only form pinned in TimeBoundsTest alongside it.

Epoch seconds are not accepted and cannot be: a ten-digit number parses as milliseconds,
so it means January 1970 rather than failing. Nothing is pruned, since no index matches
that window, but the doc now says so instead of leaving it to be discovered.

Verified after the change: every listed form prunes, epoch seconds and malformed values
decline.

Signed-off-by: Kai Huang <ahkcs@amazon.com>

Author: ahkcs

core/src/test/java/org/opensearch/sql/executor/TimeBoundsTest.java

@@ -32,6 +32,8 @@ private static Stream<Arguments> boundSpellings() {
         arguments("date math with rounding", "now-1d/d", "now/d"),
         // What Dashboards sends.
         arguments("dashboards format", "2026-09-09 22:00:00.000", "2026-09-09 22:30:00.000"),
+        arguments("space, no millis", "2026-09-09 22:00:00", "2026-09-09 22:30:00"),
+        arguments("date only", "2026-09-09", "2026-09-10"),
         arguments("ISO-8601 instant", "2026-09-09T22:00:00.000Z", "2026-09-09T22:30:00.000Z"),
         arguments("epoch millis", "1788991200000", "1788993000000"));
   }

docs/user/admin/settings.rst

@@ -235,7 +235,26 @@ Request-level time bounds
 
 ``start_time`` and ``end_time`` declare the window a request is asking about. Both are required, and both are inclusive. ``time_field`` names the field they constrain and defaults to ``@timestamp``; a caller querying an index pattern whose time field is named something else has to give it, or nothing is pruned.
 
-Accepted values are OpenSearch date math (``now-7d``), an ISO-8601 timestamp, epoch milliseconds, or ``yyyy-MM-dd HH:mm:ss.SSS``. A field mapped with some other custom date format is not pruned on. Values that cannot be used are ignored, never an error: these parameters only affect which indices are read, so a request is never rejected on their account.
+Both accept these literals, whatever format the field itself is mapped with:
+
+.. list-table::
+   :header-rows: 1
+   :widths: 34 66
+
+   * - Literal
+     - Example
+   * - OpenSearch date math
+     - ``now``, ``now-7d``, ``now-1d/d``
+   * - ISO-8601 date and time, zone optional
+     - ``2026-09-14T12:00:00.000Z``, ``2026-09-14T12:00:00+08:00``, ``2026-09-14T12:00:00``
+   * - ISO-8601 date only
+     - ``2026-09-14``
+   * - Epoch **milliseconds**
+     - ``1789329600000``
+   * - Date and time separated by a space
+     - ``2026-09-14 12:00:00.000``, ``2026-09-14 12:00:00``
+
+Epoch seconds are not accepted -- a ten-digit number is read as milliseconds, so ``1789329600`` means January 1970. Anything else, including a malformed value, is ignored: these parameters only affect which indices are read, so a request is never rejected on their account, and nothing is pruned.
 
 Send them only alongside an equivalent filter in the query -- a ``where`` clause on the same field and range. The result is then identical to the query without them. They are not themselves a filter: they exclude whole indices, so a window the query does not also restrict returns fewer rows, and an index not mapping ``time_field`` is excluded from every window.
 

opensearch/src/main/java/org/opensearch/sql/opensearch/request/IndexPruner.java

@@ -44,7 +44,7 @@ public class IndexPruner {
    * produces.
    */
   private static final String BOUND_FORMATS =
-      "strict_date_optional_time||epoch_millis||yyyy-MM-dd HH:mm:ss.SSS";
+      "strict_date_optional_time||epoch_millis||yyyy-MM-dd HH:mm:ss.SSS||yyyy-MM-dd HH:mm:ss";
 
   /** Both probes are transport actions, so only the node client can issue them. */
   private final NodeClient node;