- tototoshi/slick-joda-mapper#30 で
Calender
を使う実装がはいった - 具体的なところは
mysql-connector-java
の実装による疑惑があるが、setTimestamp
でCalendar
を渡すと実際にDBに対して発行されるINSERT
などのクエリーの時間の表現が変化すると思われる-
Calendarオブジェクトを使用すると、ドライバはカスタム・タイムゾーンを考慮してタイムスタンプを計算できます。
- https://docs.oracle.com/javase/jp/8/docs/api/java/sql/PreparedStatement.html#setTimestamp-int-java.sql.Timestamp-java.util.Calendar-
-
- ただ👇下記のようにタイムゾーンを変更した時間をDBに入れるテストを追加すると
Calendar
を利用するとおかしなことが起きてしまう - 吉田さんのPR tototoshi/slick-joda-mapper#77 では、互換性を考慮して
Calender
を利用しない(tototoshi/slick-joda-mapper#30 が入る前の実装)に戻せるよう方法が追加された- この実装だと上記のテストは全てSuccessする
- まず、現在は次のようにグローバルな設定をやっている
Locale.setDefault(Locale.JAPAN) val tz = TimeZone.getTimeZone("Asia/Tokyo") TimeZone.setDefault(tz) DateTimeZone.setDefault(DateTimeZone.forID(tz.getID))
- そしてテストの結果がこのようになる
[info] - should be the same in/out joda-time zoned Asia/Tokyo [info] - should be the same in/out joda-time zoned UTC *** FAILED *** [info] 1354806000000 was not equal to 1354838400000 (JodaSupportSpec.scala:252) [info] - should be the same in/out joda-time zoned Europe/London *** FAILED *** [info] 1354806000000 was not equal to 1354838400000 (JodaSupportSpec.scala:252) [info] - should be the same in/out joda-time zoned America/New_York *** FAILED *** [info] 1354806000000 was not equal to 1354856400000 (JodaSupportSpec.scala:252)
- 保存される
DateTime
のゾーンがjava.util.TimeZone
のグローバル設定と異なるときに発生していると考えられる- たとえば下記のように
java.util.TimeZone
をUTC
に設定すると、UTC
とEurope/London
は通って他が落ちるというようになる
val tz = TimeZone.getTimeZone("UTC") TimeZone.setDefault(tz)
- たとえば下記のように
- 吉田さんのPRは互換性に最大限配慮されていて、tototoshi/slick-joda-mapper#77 をマージしても基本現在の利用者に影響はない
- PRのコメントにもあるように、最初も自分はそれで「なおってないじゃないか🤔」と勘違いしてました……😇
- 吉田さんのPRがマージされたあとの修正バージョンを使いたい人は、下記のように明示的に使う必要がある
- val jodaSupport = com.github.tototoshi.slick.MySQLJodaSupport + val jodaSupport = new com.github.tototoshi.slick.GenericJodaSupport(MySQLProfile, _ => None)