-
Notifications
You must be signed in to change notification settings - Fork 3.7k
[fix](Nereids) fix cast string to date #46065
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
4dea898 to
8b451f1
Compare
|
run buildall |
|
PR approved by at least one committer and no changes requested. |
|
PR approved by anyone and no changes requested. |
TPC-H: Total hot run time: 32559 ms |
TPC-DS: Total hot run time: 196980 ms |
ClickBench: Total hot run time: 31.65 s |
|
run buildall |
TPC-H: Total hot run time: 32875 ms |
|
run buildall |
TPC-H: Total hot run time: 32394 ms |
TPC-DS: Total hot run time: 197896 ms |
ClickBench: Total hot run time: 31.25 s |
|
run buildall |
TPC-H: Total hot run time: 32439 ms |
TPC-DS: Total hot run time: 190309 ms |
ClickBench: Total hot run time: 31.63 s |
|
run p0 |
|
PR approved by at least one committer and no changes requested. |
| sb.append("20"); | ||
| } else if (year >= 70 && year <= 99) { | ||
| sb.append("19"); | ||
| if (s.charAt(j) == '.') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why "201.01.01" is year 2020, but "201-01-01" is year 201
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this behavior is align to mysql
### What problem does this PR solve? Issue Number: close #xxx Related PR: #35637 Problem Summary: When cast("201-01-01" as datetimev2(0)), The result is "2020-01-01" but it is wrong. It should be result in "0201-01-01". 201 would be regarded as 20xy-0z as related pr show, it was a bug. But actually it should not have this trasformation and result in
Issue Number: close #xxx Related PR: apache#35637 Problem Summary: When cast("201-01-01" as datetimev2(0)), The result is "2020-01-01" but it is wrong. It should be result in "0201-01-01". 201 would be regarded as 20xy-0z as related pr show, it was a bug. But actually it should not have this trasformation and result in
Issue Number: close #xxx Related PR: apache#35637 Problem Summary: When cast("201-01-01" as datetimev2(0)), The result is "2020-01-01" but it is wrong. It should be result in "0201-01-01". 201 would be regarded as 20xy-0z as related pr show, it was a bug. But actually it should not have this trasformation and result in
Issue Number: close #xxx Related PR: apache#35637 Problem Summary: When cast("201-01-01" as datetimev2(0)), The result is "2020-01-01" but it is wrong. It should be result in "0201-01-01". 201 would be regarded as 20xy-0z as related pr show, it was a bug. But actually it should not have this trasformation and result in
pick: #46065 Related PR: #35637 Problem Summary: When cast("201-01-01" as datetimev2(0)), The result is "2020-01-01" but it is wrong. It should be result in "0201-01-01". 201 would be regarded as 20xy-0z as related pr show, it was a bug. But actually it should not have this trasformation and result in
What problem does this PR solve?
Issue Number: close #xxx
Related PR: #35637
Problem Summary:
When cast("201-01-01" as datetimev2(0)), The result is "2020-01-01" but it is wrong. It should be result in "0201-01-01".
201 would be regarded as 20xy-0z as related pr show, it was a bug. But actually it should not have this trasformation and result in
Release note
None
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)