class reference conflict:org.apache.ibatis.type.ZonedDateTimeTypeHandler in [mybatis/mybatis-3] and [mybatis/typehandlers-jsr310]

[MRX151]

These two repo both have this ZonedDateTimeTypeHandler.class with the same reference,which means when I use them both in my maven dependencies,first one will be valid.

But their implementations are different and I believe the implementation in [mybatis-3] has bug :

  @Override
  public ZonedDateTime getNullableResult(ResultSet rs, String columnName) throws SQLException {
    return rs.getObject(columnName, ZonedDateTime.class);
  }

  @Override
  public ZonedDateTime getNullableResult(ResultSet rs, int columnIndex) throws SQLException {
    return rs.getObject(columnIndex, ZonedDateTime.class);
  }

  @Override
  public ZonedDateTime getNullableResult(CallableStatement cs, int columnIndex) throws SQLException {
    return cs.getObject(columnIndex, ZonedDateTime.class);
  }

when I use this implementation in my project,it throws exception.Maybe can't cast ZonedDateTime form result directly?

Howerver,implementation in [mybatis/typehandlers-jsr310] goes fine:

  @Override
  public ZonedDateTime getNullableResult(ResultSet rs, String columnName) throws SQLException {
    Timestamp timestamp = rs.getTimestamp(columnName);
    return getZonedDateTime(timestamp);
  }

  private static ZonedDateTime getZonedDateTime(Timestamp timestamp) {
    if (timestamp != null) {
      return ZonedDateTime.ofInstant(timestamp.toInstant(), ZoneId.systemDefault());
    }
    return null;
  }

cast it to Timestamp first and to ZonedDateTime later.

btw: I have test the LocalDateTime/LocalDate/Instant Type,they work well in mybatis-3

Maybe you can merage this org.apache.ibatis.type.ZonedDateTimeTypeHandler to the main repo?

[harawata]

Hi @MRX151 ,

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

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

The new implementation satisfies these conditions, but it requires the database to support storing zone information and not many databases support it (I could find only one i.e. Oracle).

The old implementation didn't satisfy both 1 and 2, but it may have seemed to satisfy 2 if you always used the default time zone (i.e. ZoneId.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.

[MRX151]

@harawata oh, I understand,thank you for the answering!