types: year function can't handle some date string

[yuqi1129]

What problem does this PR solve?

Issue Number: close #26151

Check List

Tests

• Unit test

Release note

• No release note.

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has not been approved.

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

The full list of commands accepted by this bot can be found here.

Reviewer can indicate their review by submitting an approval review.
Reviewer can cancel approval by submitting a request changes review.

[sre-bot]

Please follow PR Title Format:

• pkg [, pkg2, pkg3]: what's changed

Or if the count of mainly changed packages are more than 3, use

• *: what's changed

[yuqi1129]

/cc @wshwsh12 @lzmhhh123

[yuqi1129]

/cc @tisonkun

[yuqi1129]

@wshwsh12 @tisonkun , Can you review again ?

[tisonkun]

@yuqi1129 can you give a brief analyze for the issue and your solution? Or comment on the original issue and refer from here.

This patch plays a lot low level manipulation which is theoretically brittle.

[yuqi1129]

@tisonkun
Take the date string 12:12:12:(length 9) and 12:12:12:::; (length 12), when come to the end of function ParseDateFormat, the value of start is 6(the last index of valid number split by ':') and 12(this means start come to end of date string), when the date string is normal like '2020-12-12'(start is 8), the algorithm currently used is OK but not some special case

My solution. as mention above, we should handle two case: start values equal to the length of string and substring from start to end contains invalid character.

for end = start; end < len(format) && !isValidSeparator(format[end], len(seps)); end++ {
}

I introduce variance end to represent the first invalid character from start index

if end != start

This is to handle the case when start equals to the length of date string

Another resolution: refactor the whole ParseDateFormat.

[tisonkun]

@wshwsh12 is this function potentially pushed down to coprocessor? I'm afraid that TiKV or TiFlash implementation are different.

[tisonkun]

IIRC golang builtin provides math.Min already, and github.com/cznic/mathutil is archived.

[yuqi1129]

@tisonkun You mean the built-in math.Min?, it only has double64 parameter method, correct me if i'am wrong

[tisonkun]

@wshwsh12 @lzmhhh123 PTAL

[tisonkun]

@wshwsh12 @lzmhhh123 PTAL

[wshwsh12]

Is this function potentially pushed down to coprocessor?

Yes. CaseXXXasTime maybe call the parse function. And the funtions have been push down to coprocessor.

[wshwsh12]

Seem some cases will also get wrong result.
For example.

[tidb]> select year('2011-11-11x');
ERROR 1105 (HY000): strconv.Atoi: parsing "11x": invalid syntax

But I don't have a good idea to cover all corner cases.