MyBatis OffsetDateTimeTypeHandler had a breaking change from 3.4.6 -> 3.5.3

Java Version

OpenJdk 11.0.2

MyBatis version

3.5.3

Database vendor and version

MySql 5.7

Description

I am upgrading

FROM

"org.mybatis:mybatis:3.4.6",

TO

"org.mybatis:mybatis:3.5.3"

During that process I noticed that that the OffsetDateTimeTypeHandler seemed to have a breaking change, and or maybe a bug.

https://github.com/mybatis/mybatis-3/blob/mybatis-3.4.6/src/main/java/org/apache/ibatis/type/OffsetDateTimeTypeHandler.java

vs

https://github.com/mybatis/mybatis-3/blob/mybatis-3.5.3/src/main/java/org/apache/ibatis/type/OffsetDateTimeTypeHandler.java

It seems internal logic for handling the serialization and deserialization has been removed.

Expected result

INSERT INTO
        CATEGORY
          (
            ID,
            DISPLAY_NAME,
            PATH,
            CREATED_BY,
            LAST_UPDATED_BY,
            CREATED_TS,
            LAST_UPDATED_TS
          )
      VALUES
        (
          '64fa6430-8df9-40d0-9f3c-4caab5dfe403',
          'MyCategory',
          'mycategory',
          'TODO',
          'TODO',
          ** STREAM DATA **, <-- REAL TIMESTAMPS HERE
          ** STREAM DATA ** <-- REAL TIMESTAMPS HERE
        )

Actual result

```INSERT INTO CATEGORY ( ID, DISPLAY_NAME, PATH, CREATED_BY, LAST_UPDATED_BY, CREATED_TS, LAST_UPDATED_TS ) VALUES ( '64fa6430-8df9-40d0-9f3c-4caab5dfe403', 'MyCategory', 'mycategory', 'TODO', 'TODO', ** STREAM DATA **, ** STREAM DATA ** )

## Workaround

I copied the old class and stored a copy in my project and wired it up via

@Bean ConfigurationCustomizer mybatisConfigurationCustomizer(@Value("${cms.mybatis.cache.enabled:#{false}}") boolean isCacheEnabled) { return configuration -> { configuration.setCacheEnabled(isCacheEnabled); // For some reason the built in OffsetDateTimeTypeHandler doesn't work like it did in the guice module configuration.getTypeHandlerRegistry() .register(OffsetDateTime.class, new OffsetDateTimeTypeHandler()); }; } } ```

Comment From: harawata

Hi @fieldju ,

It's not a bug. From Java point of view, the expected behavior would be...

1. When you persist a OffsetDateTime, the offset information should be stored in the database as well (even if it's different from the system's offset).
2. When you persist a OffsetDateTime instance and then retrieve it, the returned OffsetDateTime should have the same offset as the inserted one (even when it's different from the system's offset).

The new implementation satisfies these conditions, but it requires the database to support storing offset information and MySQL does not support it (see https://github.com/mybatis/mybatis-3/pull/1368#issuecomment-428922657).

The old implementation didn't satisfy both 1 and 2, but it may have seemed to satisfy 2 if you always used the default offset (i.e. ZoneOffset.systemDefault()).

The current workaround is to copy the old implementation to your project and register it in the config. Please let us know if you need further assistance. (You already did this. Forgot to edit the template :))

Comment From: harawata

Closing. Please let me know if my explanation is unclear.