Skip to content

Conversation

@jacktengg
Copy link
Contributor

apache/doris-website#2962

TIMESTAMPTZ implementation does not store time zone information with each row of data, but instead adopts the following mechanism:

  1. During storage: All input time values are converted to UTC (Coordinated Universal Time)
  2. During query: Based on the session's time zone setting (specified via the time_zone variable), UTC time is automatically converted to the corresponding time zone for display

Therefore, TIMESTAMPTZ can be understood as a DATETIME type with time zone conversion functionality, where Doris automatically handles time zone conversions internally.

None

  • Test

    • Regression test
    • Unit Test
    • Manual test (add detailed scripts or steps below)
    • No need to test or manual test. Explain why:
  • This is a refactor/code format and no logic has been changed.
    - [ ] Previous test can cover this change. - [ ] No code files have been changed. - [ ] Other reason

  • Behavior changed:

    • No.
    • Yes.
  • Does this need documentation?

    • No.
  • Yes.

  • Confirm the release note

  • Confirm test cases

  • Confirm document

  • Add branch pick label


What problem does this PR solve?

Issue Number: close #xxx

Related PR: #xxx

Problem Summary:

Release note

None

Check List (For Author)

  • Test

    • Regression test
    • Unit Test
    • Manual test (add detailed scripts or steps below)
    • No need to test or manual test. Explain why:
      • This is a refactor/code format and no logic has been changed.
      • Previous test can cover this change.
      • No code files have been changed.
      • Other reason
  • Behavior changed:

    • No.
    • Yes.
  • Does this need documentation?

    • No.
    • Yes.

Check List (For Reviewer who merge this PR)

  • Confirm the release note
  • Confirm test cases
  • Confirm document
  • Add branch pick label

apache/doris-website#2962

TIMESTAMPTZ implementation does not store time zone information with
each row of data, but instead adopts the following mechanism:
1. During storage: All input time values are converted to UTC
(Coordinated Universal Time)
2. During query: Based on the session's time zone setting (specified via
the `time_zone` variable), UTC time is automatically converted to the
corresponding time zone for display

Therefore, TIMESTAMPTZ can be understood as a DATETIME type with time
zone conversion functionality, where Doris automatically handles time
zone conversions internally.

None

- Test <!-- At least one of them must be included. -->
    - [x] Regression test
    - [x] Unit Test
    - [ ] Manual test (add detailed scripts or steps below)
    - [ ] No need to test or manual test. Explain why:
- [ ] This is a refactor/code format and no logic has been changed.
        - [ ] Previous test can cover this change.
        - [ ] No code files have been changed.
        - [ ] Other reason <!-- Add your reason?  -->

- Behavior changed:
    - [x] No.
    - [ ] Yes. <!-- Explain the behavior change -->

- Does this need documentation?
    - [ ] No.
- [x] Yes. <!-- Add document PR link here. eg:
apache/doris-website#1214 -->

- [ ] Confirm the release note
- [ ] Confirm test cases
- [ ] Confirm document
- [ ] Add branch pick label <!-- Add branch pick label that this PR
should merge into -->

---------

Co-authored-by: jacktengg <tengjianping@selectdb.com>
@jacktengg jacktengg requested a review from yiguolei as a code owner December 26, 2025 07:49
@Thearas
Copy link
Contributor

Thearas commented Dec 26, 2025

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?

@jacktengg
Copy link
Contributor Author

run buildall

@hello-stephen
Copy link
Contributor

Cloud UT Coverage Report

Increment line coverage 🎉

Increment coverage report
Complete coverage report

Category Coverage
Function Coverage 82.10% (1573/1916)
Line Coverage 67.11% (28069/41824)
Region Coverage 67.58% (13803/20426)
Branch Coverage 58.04% (7362/12684)

@hello-stephen
Copy link
Contributor

FE UT Coverage Report

Increment line coverage 19.54% (77/394) 🎉
Increment coverage report
Complete coverage report

@jacktengg
Copy link
Contributor Author

run buildall

@hello-stephen
Copy link
Contributor

Cloud UT Coverage Report

Increment line coverage 🎉

Increment coverage report
Complete coverage report

Category Coverage
Function Coverage 82.10% (1573/1916)
Line Coverage 67.11% (28068/41824)
Region Coverage 67.63% (13815/20426)
Branch Coverage 58.01% (7358/12684)

@hello-stephen
Copy link
Contributor

FE UT Coverage Report

Increment line coverage 19.54% (77/394) 🎉
Increment coverage report
Complete coverage report

@doris-robot
Copy link

BE UT Coverage Report

Increment line coverage 57.24% (692/1209) 🎉

Increment coverage report
Complete coverage report

Category Coverage
Function Coverage 53.34% (18663/34988)
Line Coverage 39.10% (172830/442002)
Region Coverage 33.77% (133560/395454)
Branch Coverage 34.75% (57743/166148)

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.

5 participants