Add support for more JSR-310 related classes in IntervalShardingAlgorithm

Feature Request

For English only, other languages will not accept.

Please pay attention on issues you submitted, because we maybe need more details. If no response anymore and we cannot make decision by current information, we will close it.

Please answer these questions before submitting your issue. Thanks!

Is your feature request related to a problem?

No, but related to https://github.com/apache/shardingsphere/pull/16740 .

Describe the feature you would like.

• The current IntervalShardingAlgorithm does not support java.time.Instant and more about JSR-310, which will cause trouble to the use of Mybatis.

• because for Mybatis 3.5.9, the built-in typeHandlers in the typeHandlers that can convert the JDBC type of TIMESTAMP can be converted to java.util.Date, java.sql.Timestamp, java.time.Instant, java.time.LocalDateTime, java.time.OffsetDateTime, java.time.ZonedDateTime .

• Supporting more JSR-310 classes is an expected behavior.

• Refer to https://mybatis.org/mybatis-3/zh/configuration.html#typeHandlers.

[complone]

• My intuitive understanding is that once we decide to introduce a class like java.time.LocalDate in IntervalShardingAlgorithm, the corresponding JDBC Type is not a Timestamp class, then LocalDateTime should not be forced to be defined in IntervalShardingAlgorithm, but with the help of Its superclass or specific interface to help us deal with incoming classes, which more needs to take into account the private static final String DATE_TIME_PATTERN_KEY = "datetime-pattern"; in the configuration.
• update: It seems that Support for advanced IntervalShardingAlgorithm #17814 is trying to do string matching on the datetime-pattern or actualdatanodes of IntervalShardingAlgorithm, I would like to see his approach first and then deal with the string matching problem of this issue.

@linghengqian By reading the issue, I sorted out some key information For example, there are some new APIs in Java8, LocalDate, LocalTime, LocalDateTime But by default, the time and date of java8 is not supported in mybatis

The general approach is based on the different typehandlers provided by mybatis based on the package mybatis-typehandlers-jsr310 Complete the conversion of various java types to mysql types, but the principle of typehandler is Based on a registered factory for the TypeHandlerRegistry class, the commonly used converters are initialized by default in this class, There are the following two Maps in the member variables, among which JDBC_TYPE_HANDLER_MAP This map is for the conversion of jdbc to Java class, There are certain limitations

After looking around I think LocalDateTime is a superior abstraction of LocalDate There is an intermediary between ChronoLocalDateTime and ChronoLocalDateLocalTime to query the specific time point Termquery is a functional interface annotated with @FunctionalInterface Queries are key tools for extracting information from temporal objects. According to the strategy design pattern, The purpose is to externalize the query process, allowing different methods to be used Termquery

In order to mask the underlying details as much as possible, I found a solution based on java api Termquery.

Here is [an example of time transformation in [graphsql](https://github.com/smallrye/smallrye-graphql/blob/main/server/implementation/src/main/java/io/smallrye/graphql/transformation/LegacyDateTransformer. java)

Hope it helps your work

[linghengqian]

• @terrymanu There are still unprocessed JSR-310 classes, can I reopen this issue?

• update: I will open a new issue shortly to supplement the unsupported class information for this issue to stagger the 5.12 milestone