Skip to content

fix(integ): use engine-zone today in DateTimeFunctionIT now()-based assertions#5553

Merged
ahkcs merged 1 commit into
opensearch-project:mainfrom
ahkcs:fix/datetime-function-utc-now
Jun 16, 2026
Merged

fix(integ): use engine-zone today in DateTimeFunctionIT now()-based assertions#5553
ahkcs merged 1 commit into
opensearch-project:mainfrom
ahkcs:fix/datetime-function-utc-now

Conversation

@ahkcs

@ahkcs ahkcs commented Jun 16, 2026

Copy link
Copy Markdown
Collaborator

Summary

DateTimeFunctionIT's adddate/subdate-with-TIME tests assert against a current date the query engine supplies — e.g. adddate(TIME('07:40:00'), interval 1 day) → today+1. The expected value was computed with LocalDate.now() (JVM default zone), but the analytics-engine route resolves now()/curdate() in UTC. When a run starts after the local/UTC date boundary (e.g. 17:xx PDT = 00:xx UTC), the two dates differ by one day and the now()-based tests fail with an off-by-one-day timestamp.

Same class of bug fixed for DateTimeComparisonIT in #5543, surfacing in a different IT — newly visible because the analytics route only recently gained now()-family support.

Fix

Add an engineToday() helper:

private LocalDate engineToday() {
  return isAnalyticsParquetIndicesEnabled() ? LocalDate.now(ZoneOffset.UTC) : LocalDate.now();
}

and route the 10 LocalDate.now() assertion sites through it. The v2/Calcite-over-Lucene branch (: LocalDate.now()) is byte-identical to the prior behavior, so that path cannot regress; only the analytics route changes to match the engine's UTC clock. Pure test change, no production code.

Before / After

CalciteDateTimeFunctionIT on the analytics-engine route, run started 17:32 PDT = 00:32 UTC (inside the boundary window):

Test Before After
testDateAdd FAIL (off by 1 day) PASS
testDateSub FAIL PASS
testAddDateWithDays FAIL PASS
testSubDateDays FAIL PASS
testAddDateWithInterval FAIL PASS
testSubDateInterval FAIL PASS
class total 57/65 60/65

The 2 still-failing tests (testDateFormat %c zero-padding, testStrftimeWithDateFields sub-millisecond precision) are unrelated backend format/precision gaps, out of scope here.

Test plan

  • ./gradlew :integ-test:integTestRemote --tests '*.CalciteDateTimeFunctionIT' against an analytics-engine cluster, run inside the UTC-boundary window — the 6 now()-based tests pass.
  • v2 branch is byte-identical to the original LocalDate.now() — no behavior change off the analytics route.

…ssertions

The adddate/subdate-with-TIME tests assert against a current date the query
engine supplies (e.g. adddate(TIME('07:40:00'), interval 1 day) → today+1).
The expected value was computed with LocalDate.now() (JVM default zone), but
the analytics-engine route resolves now()/curdate() in UTC. When a run starts
after the local/UTC date boundary (e.g. 17:xx PDT = 00:xx UTC), the two dates
differ by one day and the now()-based tests fail with an off-by-one-day
timestamp.

This is the same class of bug fixed for DateTimeComparisonIT in opensearch-project#5543, in a
different IT. Add an engineToday() helper that returns LocalDate.now(UTC) on
the analytics route and LocalDate.now() otherwise; the v2/Calcite-over-Lucene
branch is byte-identical to the previous behavior, so that path cannot regress.

Verified on the analytics-engine route with the run started at 17:32 PDT
(= 00:32 UTC, inside the boundary window): the 6 now()-based tests
(testDateAdd, testDateSub, testAddDateWithDays, testSubDateDays,
testAddDateWithInterval, testSubDateInterval) all pass. The 2 remaining
CalciteDateTimeFunctionIT failures (testDateFormat %c padding,
testStrftimeWithDateFields sub-millisecond precision) are unrelated
format/precision gaps and out of scope here.

Signed-off-by: Kai Huang <ahkcs@amazon.com>
@ahkcs ahkcs merged commit 9663d5f into opensearch-project:main Jun 16, 2026
27 of 32 checks passed
@ahkcs ahkcs deleted the fix/datetime-function-utc-now branch June 16, 2026 18:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants