The `timestampadd()` function handles time precision abnormally

[apollodafoni]

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

create table lrr_test(`COL1` datetime(2) NOT NULL);
insert into lrr_test values('2024-01-01 00:00:00.32');
insert into lrr_test values('2024-01-01 00:02:00.00');
select col1, timestampadd(hour, 1, col1) from lrr_test;

2. What did you expect to see? (Required)

Mysql： +------------------------+-----------------------------+ | col1 | timestampadd(hour, 1, col1) | +------------------------+-----------------------------+ | 2024-01-01 00:02:00.00 | 2024-01-01 01:02:00.00 | | 2024-01-01 00:00:00.32 | 2024-01-01 01:00:00.32 | +------------------------+-----------------------------+ After timestampadd() function processing, two decimal places are retained

3. What did you see instead (Required)

+------------------------+-----------------------------+ | col1 | timestampadd(hour, 1, col1) | +------------------------+-----------------------------+ | 2024-01-01 00:00:00.32 | 2024-01-01 01:00:00.320000 | | 2024-01-01 00:02:00.00 | 2024-01-01 01:02:00 | +------------------------+-----------------------------+ Some retain six decimal places. If it is .00, no decimal places are retained.

4. What is your TiDB version? (Required)

Release Version: v8.5.0-alpha-7-g22a175b384 Edition: Community Git Commit Hash: 22a175b384d6e171641e0aa0d3d8b9c15a92a935 Git Branch: HEAD UTC Build Time: 2024-10-30 05:21:13 GoVersion: go1.23.2 Race Enabled: false Check Table Before Drop: false Store: tikv

[apollodafoni]

/severity moderate /sig execution

[apollodafoni]

It may be related to the implementation mechanism of timestampadd(), which can be seen together with this issue(https://github.com/pingcap/tidb/issues/56870)

[windtalker]

Yes, I think it is similar with #56870 as timestampadd returns string type.

[apollodafoni]

/label fuzz/comp