expression: fix TIMESTAMP func get wrong result with decimal (#15185) (#20088)

[ti-srebot]

cherry-pick #20088 to release-3.0

---

What problem does this PR solve?

Issue Number: close #15185

Problem Summary:
The TIMESTAMP function deal with argument of decimal/float will get wrong result.
e.g.:
Run sql :
SELECT TIMESTAMP(11111.1111);
Expected:
2001-11-11 00:00:00.0000
Actual:
2011-11-01 11:11:00.0000

The reason is that the parse logic of datetime is different when dealing with strings and numbers.

In short, when dealing with numbers, if number length are not 6, 8, 12, 14, the parse logic should padded with leading zeros to the closest length.

When dealing with strings, the parse logic will interpreted from left to right to find year, month, day, hour... for as many parts as are present in the string.

For more details, see
https://dev.mysql.com/doc/refman/5.7/en/date-and-time-literals.html.
https://github.com/mysql/mysql-server/blob/5.7/sql-common/my_time.c

What is changed and how it works?

What's Changed:
The original code treat strings and numbers as all the same.
To spilt that logic, I redirect method call of parseDateTime() to ParseDatetimeFromNum() when the flag "isFloat" is true.

Check List

Tests

• Unit test
• Integration test

Release note

• fix function timestamp() get wrong result when input argument is type of float/decimal

[ti-srebot]

/run-all-tests

[ichn-hu]

@LENSHOOD Hi, would you like to resolve the conflicts of this cherry-pick?

[LENSHOOD]

@LENSHOOD Hi, would you like to resolve the conflicts of this cherry-pick?

sure, i'll give it a try.

[LENSHOOD]

@LENSHOOD Hi, would you like to resolve the conflicts of this cherry-pick?

sure, i'll give it a try.

@ichn-hu PTAL ti-srebot#8

[LENSHOOD]

@ti-srebot /run-all-tests

[LENSHOOD]

@ti-srebot /run-sqllogic-test-1

[ichn-hu]

LGTM

[ichn-hu]

@lzmhhh123 PTAL

[lzmhhh123]

LGTM

[bb7133]

/merge

[ti-srebot]

Sorry @bb7133, this branch cannot be merged without an approval of release maintainers

[bb7133]

/run-all-tests