See mybatis/mybatis-3#977

ThreeTen-Extra is a small library that builds on the Java SE 8 java.time package. It provides some additional classes that come in handy as value types.

We use it quite often in our projects and we already have several converters in place. Would be nice if we could add these type converters to mybatis/typehandlers-jsr310.

I don't think it would make sense to add a compile scope dependency to threeten-extra. Is there any other way to add type converters to this project? I do know some maven intrinsics but dependency scopes like optional and runtime I do not know much.

Edit
In my repo I added threeten-extra as an optional dependency.

<dependency>
  <groupId>org.threeten</groupId>
  <artifactId>threeten-extra</artifactId>
  <version>1.0</version>
  <scope>compile</scope>
  <optional>true</optional>
</dependency>

Now I can use typehandlers-jsr310 in my project even if threeten-extra is not included. Adding threeten-extra allows me to use the additional typehandlers.

We just can't auto register the threeten-extra typehandlers in mybatis-3, since we don't know if threeten-extra is included or not.

Update as follow:

• Update version from 1.0.1 to 1.0.2
• Add the YearMonthTypeHandler
• Add the JapaneseDateTypeHandler

I'm unable to build this module on my local machine. Possibly something with daylight savings time not sure.

Build always works fine on travis-ci.

Here is what I get locally. I'm in US Eastern time zone.

Failed tests:
  JapaneseDateTypeHandlerTest.shouldGetResultFromCallableStatement:76 expected:<Japanese Heisei 28-12-29> but was:<Japanese Heisei 28-12-28>
  JapaneseDateTypeHandlerTest.shouldGetResultFromResultSetByName:46 expected:<Japanese Heisei 28-12-29> but was:<Japanese Heisei 28-12-28>
  JapaneseDateTypeHandlerTest.shouldGetResultFromResultSetByPosition:61 expected:<Japanese Heisei 28-12-29> but was:<Japanese Heisei 28-12-28>

refs #12

I think there is something wrong in MANIFEST.MF generation.

In version 1.0.1 we have this:

Private-Package: org.apache.ibatis.type

Which makes all handlers invisble when running in for example Karaf.

When looking at the POM's (both this one and parent) it seems correct.
In parent we add Private-Package only if the property ${osgi.private} is set and it's not set in this projects pom from what I can see but still we get the header in MANIFEST.MF

parameter 为null的情况下，Time.valueOf(parameter);会出问题。

See mybatis/mybatis-3#974

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!

See #47 (comment)

Related issues

• mybatis/mybatis-3#974

parameter 为null的情况下，Time.valueOf(parameter);会出问题。
其他地方的差不多。
example:
改成：
if (parameter == null) {
ps.setTime(i, null);
} else {
ps.setTime(i, Time.valueOf(parameter));
}