`CONVERT_TZ` is not compatible with MySQL for edging value
- Dominant language
- Go
- Stars
- 40.5k
- Forks
- 6.2k
- PR merge metrics
- PR metrics pending
Description
## Bug Report
Please answer these questions before submitting your issue. Thanks!
### 1. Minimal reproduce step (Required)
### 2. What did you expect to see? (Required)
```
mysql> SELECT CONVERT_TZ('0000-01-01 00:00:00', '+00:00', '+01:00');
+-------------------------------------------------------+
| CONVERT_TZ('0000-01-01 00:00:00', '+00:00', '+01:00') |
+-------------------------------------------------------+
| 0000-01-01 00:00:00 |
+-------------------------------------------------------+
1 row in set (0.01 sec)
mysql> SELECT CONVERT_TZ('9999-12-31 23:59:59', 'UTC', 'Asia/Kolkata');
+----------------------------------------------------------+
| CONVERT_TZ('9999-12-31 23:59:59', 'UTC', 'Asia/Kolkata') |
+----------------------------------------------------------+
| 9999-12-31 23:59:59 |
+----------------------------------------------------------+
1 row in set (0.00 sec)
```
### 3. What did you see instead (Required)
```
mysql> SELECT CONVERT_TZ('0000-01-01 00:00:00', '+00:00', '+01:00');
+-------------------------------------------------------+
| CONVERT_TZ('0000-01-01 00:00:00', '+00:00', '+01:00') |
+-------------------------------------------------------+
| 0000-01-01 01:00:00 |
+-------------------------------------------------------+
1 row in set (0.00 sec)
mysql> SELECT CONVERT_TZ('9999-12-31 23:59:59', 'UTC', 'Asia/Kolkata');
+----------------------------------------------------------+
| CONVERT_TZ('9999-12-31 23:59:59', 'UTC', 'Asia/Kolkata') |
+----------------------------------------------------------+
| 10000-01-01 05:29:59 |
+----------------------------------------------------------+
1 row in set (0.00 sec)
```
### 4. What is your TiDB version? (Required)
Contributor guide
Research direction
Start by reproducing the two CONVERT_TZ queries from the issue and comparing TiDB's results with MySQL. No implementation file or test is named, so trace the CONVERT_TZ entry point and existing date/time tests; done means both edge cases match the expected MySQL results.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, mysql
- Domain
- databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100