OffsetDateTimeTypeHandler or ZonedDateTimeTypeHandler loses time zone information

[Treppenhouse]

Hello,
I would assume that people using your implementation of a "ZonedDateTimeTypeHandler" expect it to convert dates with timezone information in their database to EQUIVALENT Java objects, which it does not (really).

It merely converts them to objects that, technically point to the same moment in time, however with the zone or offset information completely lost. All the ZonedDateTime or OffsetDateTime objects that the handlers create always refer to the system default time zone, never to the one of the actual entry!

Instead of only using the getTimestamp() method of the ResultSet (which can only return a java.sql.Timestamp with the zone information already lost) it would be cool if you could at least offer an alternative implementation that tries to retain the offset/timezone information by using the getString() method instead.

An example for the OffsetDateTimeTypeHandler could be:

@Override
public OffsetDateTime getNullableResult(ResultSet rs, String columnName) throws SQLException {
  String dateString = rs.getString(columnName)
  if(dateString == null) {
    return null;
  }
  OffsetDateTime offsetDateTime = OffsetDateTime.parse(dateString, DateTimeFormatter.ISO_OFFSET_DATE_TIME);
  return offsetDateTime;
}

I found the idea here. Of course, this would assume that the String representation of the databases for those "timestamp with time zone" datatypes comply with the ISO format. Instead of guessing users could hand over the format-mask to a method that converts to the String representation of that column in the select statement. E.g. in Oracle that could be:
SELECT to_char(table0.MY_DATE_COLUMN, 'YYYY-MM-DD"T"HH24:MI:SSFFTZH:TZM') as MY_DATE_COLUMN). Such a remark could be added in the class documentation of the type handler, for example.

Even if you do not want to add such handlers, you should at least mention in your documentation (class documentation and README.MD) that the handlers you provide do NOT retain the information of the original timezone or the original offset but do always convert them to the system's default.

Cheers!

[kazuki43zoo]

@Treppenhouse Thanks for your reporting.

I've moved to mybatis/mybatis-3#1081 because type handers for JSR 310 merged into core since 3.4.5.