Skip to content

branch-4.1: [fix](be) Reject oversized Unix timestamps before year narrowing #68115 - #68364

Merged
yiguolei merged 1 commit into
branch-4.1from
auto-pick-68115-branch-4.1
Sep 23, 2026
Merged

yiguolei merged 1 commit into
branch-4.1from
auto-pick-68115-branch-4.1

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

Cherry-picked from #68115

)

### What problem does this PR solve?

Issue Number: N/A

Problem Summary:

`from_unixtime` and `from_second` / `from_millisecond` /
`from_microsecond` validate the date after converting an integer Unix
timestamp. The conversion passes the civil year to a `uint16_t` setter
first, so some out-of-range years wrap into the valid range and escape
validation. For example, in UTC, `2068116364800` seconds is year 67506,
which narrows to 1970. A BIGINT column containing this value can
therefore return `1970-01-01 00:00:00` instead of the documented
out-of-range error.

Check the timestamp before conversion using a shared upper bound of the
last second of UTC year 9999 plus one day for time zone offsets. Keep
the existing post-conversion date check for the exact local boundary and
the existing function-specific errors. The
seconds/milliseconds/microseconds functions reuse their existing
division; no additional time-zone conversion or per-row allocation is
introduced.

The regression covers both year-wrap values, BIGINT_MAX, formatted and
unformatted `from_unixtime`, all three timestamp units, literals and
table columns, constant folding enabled/disabled, NULL, and
legal/illegal boundaries in UTC, +14:00 and -12:00. The legacy
`from_unixtime` path already has a smaller upper bound. Decimal
overloads have at most 12 integer digits and cannot reach these
year-wrap inputs.

### Release note

Reject oversized integer Unix timestamps that previously wrapped into
apparently valid dates in `from_unixtime`, `from_second`,
`from_millisecond`, and `from_microsecond`.

### Check List (For Author)

- Test:
- [x] Regression test: `./run-regression-test.sh --run -d
datatype_p0/date -s test_unix_timestamp_range,test_from_unixtime` (2
suites passed). Expected output generated with `-genOut` and then
verified without generation.
- [x] Unit Test: `./run-be-ut.sh -j 48 --run
--filter='VTimestampFunctionsTest.*'` (82 passed, ASAN).
- Behavior changed:
- [x] Yes. Invalid oversized timestamps now return the existing
out-of-range error; valid time-zone boundaries remain supported.
- Does this need documentation?
    - [x] No. This restores the documented out-of-range error behavior.

Build: `./build.sh --be --fe -j 48` passed (ASAN). Validation used the
merge result with master `c4dee4bd5e8`; `git merge-tree` confirms it is
byte-for-byte identical to the tested tree.

Validation note: clang-format and build hygiene checks pass. clang-tidy
is blocked by the pre-existing unmatched `NOLINTEND` in
`be/src/core/types.h:576`; this unrelated file is unchanged.

### Check List (For Reviewer who merge this PR)

- [ ] Confirm the release note
- [ ] Confirm test cases
- [ ] Confirm document
- [ ] Add branch pick label
@github-actions
github-actions Bot requested a review from yiguolei as a code owner September 22, 2026 03:51
@hello-stephen

Copy link
Copy Markdown
Contributor

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@hello-stephen

Copy link
Copy Markdown
Contributor

run buildall

@hello-stephen

Copy link
Copy Markdown
Contributor

BE UT Coverage Report

Increment line coverage 100.00% (4/4) 🎉

Increment coverage report
Complete coverage report

Category Coverage
Function Coverage 60.12% (26112/43431)
Line Coverage 44.81% (269829/602132)
Region Coverage 40.62% (213959/526693)
Branch Coverage 42.10% (98871/234830)

@hello-stephen

Copy link
Copy Markdown
Contributor

BE Regression && UT Coverage Report

Increment line coverage 100.00% (4/4) 🎉

Increment coverage report
Complete coverage report

Category Coverage
Function Coverage 74.51% (31483/42255)
Line Coverage 58.73% (350809/597340)
Region Coverage 55.41% (292499/527877)
Branch Coverage 56.30% (132064/234567)

@github-actions

Copy link
Copy Markdown
Contributor Author

PR approved by anyone and no changes requested.

@github-actions github-actions Bot added the approved Indicates a PR has been approved by one committer. label Sep 23, 2026
@github-actions

Copy link
Copy Markdown
Contributor Author

PR approved by at least one committer and no changes requested.

@yiguolei
yiguolei merged commit 653dd61 into branch-4.1 Sep 23, 2026
35 of 36 checks passed
yiguolei pushed a commit that referenced this pull request Sep 23, 2026
…rrowing #68115 (#68364)

Cherry-picked from #68115

Co-authored-by: HappenLee <happenlee@selectdb.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by one committer. reviewed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants