[MDEV-30880] TIMESTAMP: leap second causes different query results with range access. Created: 2023-03-19 Updated: 2023-03-28 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | None |
| Affects Version/s: | 11.0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Sergei Petrunia | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
Observing leap second is not trivial so here's a complete howto: Get a time zone with leap second:
Load it into server
Restart the server. This is important. Check that you can observe leap second:
Let's create a table with a TIMESTAMP column and row with the leap second.
Rows 3 and 4 look the same when converted into DATETIME, but internally they are not:
What happens if one uses range access?
|
| Comments |
| Comment by Sergei Petrunia [ 2023-03-19 ] | |||||||||||||||||||
|
For the
| |||||||||||||||||||
| Comment by Julius Goryavsky [ 2023-03-28 ] | |||||||||||||||||||
|
gmt_sec_to_TIME() where the tmp->second+= hit correction is made at the end, which allows the code to correctly take into account the time when leap seconds are skipped, however, the time conversion from the string does not take leap seconds into account when directly converts the time string into MYSQL_TIME (or maybe through UTC, i don't known how exactly). As a result, a non-existent second is not included in the sampling interval. But when building the index, both times are converted to the same internal value (of the linear scale of seconds). And by the way, this probably never happens in practice (we didn't have negative leap seconds until at least 2023, although it could happen later this year), but imho the gmt_sec_to_TIME() code will result in SIGFAULT if the first correction in the list is negative (i == 0 but lp->ls_corr <= 0). And the "hit" value will theoretically be calculated incorrectly if lp_corr can be different from +/-1 (but this may not be possible, I may misunderstand the details of this code). |