fix(integ): use engine-zone today in DateTimeFunctionIT now()-based assertions#5553
Merged
ahkcs merged 1 commit intoJun 16, 2026
Merged
Conversation
…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>
mengweieric
approved these changes
Jun 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
DateTimeFunctionIT'sadddate/subdate-with-TIMEtests 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 withLocalDate.now()(JVM default zone), but the analytics-engine route resolvesnow()/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 thenow()-based tests fail with an off-by-one-day timestamp.Same class of bug fixed for
DateTimeComparisonITin #5543, surfacing in a different IT — newly visible because the analytics route only recently gainednow()-family support.Fix
Add an
engineToday()helper: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
CalciteDateTimeFunctionITon the analytics-engine route, run started 17:32 PDT = 00:32 UTC (inside the boundary window):testDateAddtestDateSubtestAddDateWithDaystestSubDateDaystestAddDateWithIntervaltestSubDateIntervalThe 2 still-failing tests (
testDateFormat%czero-padding,testStrftimeWithDateFieldssub-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 6now()-based tests pass.LocalDate.now()— no behavior change off the analytics route.