Jdbi: ZonedDateTimeの組み込みマッパーは、タイムゾーン情報を破棄します

正解ですが、現時点でJDBCがサポートしているのはこれだけです。 すべてのjava.timeタイプを、タイムゾーン/オフセットデータがないjava.utilまたはjava.sqlタイプに変換する必要があります。

好奇心から、Postgresを使用していますか？ タイムスタンプ付きのタイムスタンプは、予想とは異なる動作をするためです。

Postgresを使用していますか？ タイムスタンプ付きのタイムスタンプは、予想とは異なる動作をするためです。

私は承知しています。 （それ以外の点では非常に標準に準拠したデータベースに大きな失望があります。）

正解ですが、現時点でJDBCがサポートしているのはこれだけです。

JDBIが手動でこれを行う必要なしにH2のorg.h2.api.TimestampWithTimeZoneをプルすることを期待していました。
TIMESTAMP W / TZ値を取得するための「ポータブル」（さまざまなドライバー間で機能する）方法がわからないため、真の解決策はありません。
ただし、すべての情報を取得しない場合は、取得するふりをしてはなりません。つまり、IMOにはZonedDateTimeへの組み込みマッパーがないはずです。 それ以外の場合は、Postgresと同じように実行しています。私が期待することではありません。

ユーザーがZonedDateTimeを使用したいが、データベースのタイムゾーンではなくアプリサーバーのタイムゾーンで返されることを気にしない場合でも便利だと思います。

ちなみに、DropwizardはJDBI2用に異なるバージョンのマッパーを使用しています。ユーザーはデータベースのタイムゾーンを明示的に設定できます： https ：

H2でZonedDateTimeを取得/設定する方法のサンプルコードを提供していただければ、プラグインに追加させていただきます。

ユーザーがZonedDateTimeを使用したいが、データベースのタイムゾーンではなくアプリサーバーのタイムゾーンで返されることを気にしない場合でも便利だと思います。

@arteam 、ユーザーがこの選択を行うことに気付いている場合-私は同意します。

ただし、AFAIR https://github.com/jdbi/jdbi/blob/master/core/src/main/java/org/jdbi/v3/core/mapper/BuiltInMapperFactory.java#L182は、H2では機能しません。 TS w TZ、 rs.getTimestamp(..)はそのタイプではサポートされていないため。

H2でZonedDateTimeを取得/設定する方法のサンプルコードを提供できれば、それをプラグインに追加できれば幸いです。

移植可能な方法はわかりません。私が知っている唯一の方法は(org.h2.api.TimestampWithTimeZone) rs.getObject(..)あり、たとえばOracleの場合も同様ですが、Oracle固有のクラスを使用します。

一般に、正しい変換（ LocalDateTimeへのタイムスタンプ）を使用し、「ゾーン化」を明示的に追加するために、APIによって_強制_されることを好みます。

あなたは同意しないようです。つまり、この問題を開いたままにしておく意味はありません。

スタックで行うことの1つは、Javaのタイムゾーン== Postgresのタイムゾーンであると実際に主張することです。この場合、すべてが適切に機能します。 不一致がある場合、警告を発する必要がありますか？ それは、人々が期待する機能を有効にすることと、TZが正しいこととの間の妥協点としては問題ありませんか？

なぜこんなに早く閉じたのかわからないので、もっと話し合うことがあると感じました。

すべてのベンダーでこれを一般的に解決できない場合でも、ベンダーごとにこれを確実にサポートできます。

Jdbiに同梱されているマッパーと引数ファクトリは、別のマッパー/引数を登録するだけでオーバーライドできます。 最後に登録された（タイプごとに）勝ちます。

PostgresPluginのソースを見ると、 LocalDate 、 LocalTime ResultSet.getObject(Class)を使用する代替マッパーを提供するJavaTimeMapperFactoryが登録されていることがわかります。 LocalTime 、 LocalDateTime 、およびOffsetDateTimeは、PostgresJDBCドライバーによって直接サポートされています。

H2にゾーンを削除せずにZonedDateTimeを保存する方法がある場合は、 H2DatabasePluginを変更して、そのためのカスタムマッパーを使用できます。

私は今のところこれを再開します、ここで行われるべき良い議論があります、そして@findepi私たちは物事を正しく行うことに大いに気を

このコンボから、jdbiチームがhsqldb専用の引数とマッパーを提供するjdbi3-hsqldbサブプロジェクト/アーティファクト/ ...（setObject / getObjectを使用せずにjava.timeオブジェクトを直接使用することをサポートする）に関心があることを正しく理解していますか？会話）？

絶対。

正直なところ、 @ findepiに同意し

jdbiが提供するマッパーがこっそり変更されていることを誰が知っているかを知るよりも、テスト実行中に実行時例外を使用して、jdbiが特定のタイプのマッパーを提供しないことを確認してから自分で作成したいと思います。私のデータ。

多くのタイプの値を書き込んでから読み取る大規模な単体テストがあり、db自体（hsqldb）とjdbiの両方で実装の正確性/データの整合性を検証しているため、jdbiマッパー/引数を記述して問題を処理できます。 仕様がそう言っているにもかかわらず、hsqldbは現在java.timeを基本的にサポートしていないので、私は今いくつか書く必要がありました（巨大なバグ）。 私はまだ自分のシステム以外のゾーン/オフセットでjava.timeオブジェクトをテストすることを考えていなかったので、テストしただけで、確かに、オフセット/ゾーンがシステム値にリセットされて戻ってきますが、jdbiのマッピングが原因ですhsqldbのバグが原因ではなく、Timestampに送信されます。

これらの欠陥のあるマッパーをjdbi3から削除し、ベンダー固有のアーティファクト（jdbi3-hsqldbなど）に移動して、実装を完全に正しくすることをお勧めします。

とにかく、自分のプロジェクトに必要なすべてのマッパーと引数をすでに作成しているので、jdbi-hsqldbを自分で提供できる可能性があります。

私はおそらくもっと賢明な道だったと思いますが、この時点でv3がリリースされ、猫は袋から出されます。

これらのマッパーまたは引数ファクトリを削除することは、それらに依存している既存のユーザーにとって重大な変更になります。

誰かがすでにそれらに依存している場合（彼らの欠陥を認識しているかどうかにかかわらず）、私はそれらのユーザーがそれらにパッチを当てるのに十分簡単だと思います：変換はほとんどワンライナーです。 一方、それらを保持すると、提供されているために機能すると想定する私のような人々がますます増えます（正直なところ、jdbcがタイムゾーンをサポートしていないなどのすべての技術仕様を知っていますか？）後で、彼らのデータが誤って処理されていたことを知ります...
基本的に、彼らを留まらせることによる潜在的な将来の損害は、それらを削除することによって更新した少数の人々に現在引き起こされている損害よりもはるかに大きいと思います。

@TheRealMarnes機能を削除することは（存在してはならないことに同意したとしても）それほど単純ではないと思います。 人々はセマンティックバージョニングを想定する傾向があります（プロジェクトがそれに続くかどうかに関係なく）。 プロジェクトのルールはわかりませんが、通常はv3で非推奨になり（非推奨とマークできるAPIメソッドがないため、ここでは非推奨になります。ドキュメントとログが残っています）、v4で機能を削除します。 、リリースノート/移行ガイドを読むことを期待しています。

私はそのようなことは決して単純ではなく、解決策は常に誰かを不幸にするだろうと同意しますが、私は終わりが手段を正当化し、欠陥のあるシステムをより良いものに置き換えるために動揺させることは長期的には常に動揺する価値があると思う傾向があります。 そして、リリースノート/移行ガイドを読むことを期待するのは不合理だとは思いません...メンテナンスとマイナーアップデートでは確かですが、メジャーアップデートではそうではありません。 Jdbi3自体は、新しいガイドも読まないと、jdbi2からは使用できません。

それらを元に戻すことがワンライナーであるならば、私はそれらのマッパー/引数を無効にする解決策を後回しにすることができると思います-多分それらのマッパーをプラグインに移動しますか？

ベンダー固有ではないjdbi3-core-experimental ？
編集：私の悪い、あなたはjdbi.installPlugin(new ExperimentalMappersPlugin())を意味します

これらは実際には「実験的」ではありませんが、それはアイデアです。

TimezoneInsensitiveJavaTimeMappers then：P

それはマッパーだけでなく、議論の工場でもあります。

JavaTimeYoloTZPluginどうですか：wink：

すべてのベンダーでこれを一般的に解決できない場合でも、ベンダーごとにこれを確実にサポートできます。

@qualidafial最近、Java8以降の世界で日付/時刻の値を取得するための新しいデファクトスタンダードがあるようだということを知りました。

まず、もう少し背景：

• JDBIのTIMESTAMP WITH TIME ZONEからZonedDateTimeへの変換についてこの問題を作成しました。これにより、タイムゾーン情報が破棄されます。
• すべてのJDBCAPIに別の問題があります。 これが、 TIMESTAMP 、 DATE 、 TIMEオブジェクトが取得されることになっている方法です。つまり、 java.sql.{Timestamp,Date,Time}クラスを使用します。 クラスはすべてjava.util.Dateから拡張されます。 Calendarがどのように導入され、 java.util.Dateのメソッドが廃止された年/月/日/時/分/秒を処理するかを覚えている人はいますか？ 正当な理由でそうです（そして私はCalendarすべての問題を解決したという意味ではありません）。
  
  
  
  • _JVMタイムゾーン_がそのような現地時間を監視していなかった場合、データベースからjava.sql.Timestampを取得することはできません。 したがって、米国で実行されているアプリは、一部の共有データベースに2017-03-26 02:30:00 （ゾーンなし！）のタイムスタンプ値を保存できますが、ヨーロッパで実行されているアプリ（たとえば、JVMゾーンとしてEurope/Berlin ）は保存されません。当時ヨーロッパにはDSTがあったため、このタイムスタンプを取得できます。
  
  
  • ああ、これはほとんど同じクラスなので、同じことがjava.sql.Dateにも当てはまります。 java.sql.Dateは、真夜中のjava.sql.Timestampであるかのように日付を表​​しますが、真夜中がない場合もあります。 深夜（現在または過去）にDSTが変更されたゾーンがあります。
  
  
  • java.sql.Timeは、取得された時刻を1970-01-01のタイムスタンプとして表すため、この問題はないと思いますか？ 残念ながら、その日にポリシーを変更するのに十分なゾーンがあるためです（たとえば、 America/Bahia_Banderas 、 America/Hermosillo ）。 これらのゾーンでJVMが1つである場合、JDBCを使用するプログラムは特定のTIME値を取得できません。
  
  

解決策ではないのは、JDBCの古いAPIを使用して取得し、それらを新しいクラスに変換することです。 しかし、これは一般的に間違っています。

• 〜 resultSet.getTimestamp(col).toLocalDateTime() 〜
• 〜 resultSet.getDate(col).toLocalDate() 〜
• 〜 resultSet.getTime(col).toLocalTime() 〜

これはコンパイルされてうまく機能しますが、上記の問題のいずれも解決されません（JVMゾーンがPacific/Apia 、取得された日付が2011-12-30場合、日付の取得も機能しません;）

さて、新たなソリューションへ。 ResultSetはこのあまり人気のないAPIがあり、JDBCドライバーにタイプを変換するように依頼できます。

• resultSet.getObject(col, LocalDateTime.class) // for TIMESTAMP
• resultSet.getObject(col, LocalDate.class) // for DATE
• resultSet.getObject(col, LocalTime.class) // for TIME
• resultSet.getObject(col, ZonedDateTime.class) // for TIMESTAMP WITH TIME ZONE

これは、PostgreSQL、MySQL、Oracle、およびH2のJDBCドライバーで機能しているようです。 そして、魔法は、上記の「JVMゾーンでの表現不能」の問題を回避します。
この変換はSQLServerドライバーなどにはまだ実装されていませんが、JDBIが出荷するJavaTimeクラスのデフォルトのマッピングにすることができると思います。

ノート：
JDBC 4.2仕様では、ドライバーがこれを実装する必要があることを義務付けていません。 ただし、この仕様では、 PreparedStatement.setObjectとRowSet.setObjectがJava Timeクラスのインスタンスを受け入れて正しく処理する必要があるため、ドライバーはこれらのクラスを明示的にサポートする必要があります。

カッコいい！ 私の主な懸念は、このアプローチへの変更が、難解なドライバーを使用しているユーザーのリグレッションとして現れる可能性があることです。 しかし、リリースノートに適切なメッセージを送ることで、正しい方法で物事を行うという名目で、この小さな技術的に破壊的な変更を加えることができるかもしれません...

@stevenschlanskerあなたは正しいです。 JDBIが提供できると思います

• ユーザーがプラグインして元の動作を復元できるオプションのマッピングセット
• リリースノートのいくつかの適切な解説（またはメジャーバージョンのバンプ）

マイナーバージョンのままにしておきましょう。3をリリースしたばかりです。これは、間違ったままにした場合の重大な変更にすぎません...;）

私が聞いているように聞こえるものを再生するためだけに：

• 既存の組み込みjava.timeマッパーを別のプラグインに移動します（私はYoloTimePlugin好きです）
• java.sql型から変換する代わりに、 ResultSet.getObject(column, type)を使用する新しい組み込みマッパーを代わりに追加します。
• この重大な変更のたわごとをリリースノートに文書化します。この変更の影響、影響を受けるデータベースベンダー、および問題を軽減するためにユーザーが行う必要があることを説明します。

私はこれを後回しにすることができます。

ただし、これらの日付/時刻オブジェクトのバインドに関する質問にはまだ回答していません。 データベースの結果のマッピングに関して変更するものはすべて、日付/時刻引数をSQLステートメントにバインドする方法でミラーリングする必要があります。

データベースからの結果のマッピングに関して変更するものはすべて、日付/時刻引数をSQLステートメントにバインドする方法でミラーリングする必要があります。
@qualidafial 、とても良い質問です。 私はこれをテストしていません。 これはJDBC4.2仕様で明示的にカバーされているため、_正常に機能するはずです™_。

これはJDBC4.2仕様で明示的にカバーされているため、_正常に機能するはずです™_。

これは、JDBCドライバーの実装者が仕様に完全に従っていることを前提としています。 バグのないJDBCドライバーの実装はまだ見つかりません。

すべてのデータベース、およびデータ型のサポートが異なるさまざまなバージョンのマッパーをプラグインに提供するのは面倒だと感じます。 おそらく、より空白のスレートアプローチが機能する可能性があります。マッパーがプリインストールされていないJdbiインスタンスから開始し、コアアーティファクトは、手動でインストールするために選択できるさまざまなマッパーを提供します。同じデータ型を処理するためのロジックが異なるものもあります-get / setObject、get / setX、他のタイプへの変換など。データベース（バージョン）とアプリケーションロジックに最適なマッパーを自分で判断し、単体テストを使用してチェックする必要があります。

それは基本的に私が私のプロジェクトでとにかく今すでにやっていることです。 Jdbiにプリインストールされているマッパーの中には、私のデータベースでは機能しないものがあり、今のところ必要ないので、UnsupportedOperationExceptionをスローする引数/マッパーファクトリで実際にオーバーライドしました。実装（以下を参照）。

これは、dbと親密になり、すべてが完全に機能することを確認したい人にとっては解決策であり、JustWerk™（実際にはそうではない）に何かを求めている人にとっては何も変わりません。

• Jdbiインスタンスにメソッドを追加して、すべてのマッパー/引数をクリアします（クリーンスレート）
• 現在の組み込みのマッパー/引数の実装を公開して、手動でインストールできるようにします
• 代替のマッパーインプをコアアーティファクトに追加し続け、それらの需要が高まったときに、人々がそれらを自分でインストールできるようにして、以下のように可能なものを生成します

これを行うことで、私はなんとか見つけました... hsqldbドライバーで、独自の仕様から逸脱しているポイントが多すぎます（ソースで報告および修正され、更新されたアーティファクトが最終的にフリックで公開されるのをまだ待っています）、動作しました動作するマッピングロジックを自分で見つけることで、これらの欠陥を回避します。

// I want strings handled differently
<strong i="13">@Component</strong>
public class CleanStringArgumentFactory extends AbstractArgumentFactory<String> {
    protected CleanStringArgumentFactory() {
        super(Types.VARCHAR);
    }

    <strong i="14">@Override</strong>
    protected Argument build(String value, ConfigRegistry config) {
        return (position, statement, ctx) -> statement.setString(position, StringUtils.trimToNull(value));
    }
}

// no need for jdbi's built-in logic
<strong i="17">@Component</strong>
public class SetObjectArgumentFactory implements ArgumentFactory {
    private static final Set<Type> SUPPORTED = ImmutableSet.of(UUID.class, LocalDateTime.class);

    <strong i="18">@Override</strong>
    public Optional<Argument> build(Type type, Object value, ConfigRegistry config) {
        return SUPPORTED.contains(type)
            ? Optional.of(new LoggableArgument(value, (position, statement, context) -> statement.setObject(position, value)))
            : Optional.empty();
    }
}

// these built-ins don't work and I don't need them anyway
<strong i="21">@Component</strong>
public class UnsupportedArgumentFactory implements ArgumentFactory {
    private static final Set<Type> UNSUPPORTED = ImmutableSet.of(ZonedDateTime.class, OffsetDateTime.class, OffsetTime.class);

    <strong i="22">@Override</strong>
    public Optional<Argument> build(Type type, Object value, ConfigRegistry config) {
        if (UNSUPPORTED.contains(type)) {
            throw new UnsupportedOperationException(type.getTypeName() + " is not supported at the moment");
        } else {
            return Optional.empty();
        }
    }
}

// voodoo
<strong i="25">@Inject</strong>
    public JdbiConfiguration(
        @Named("dataSource") DataSource dataSource,
        Set<ArgumentFactory> arguments,
        Set<ColumnMapper> mappers,
        Set<ColumnMapperFactory> mapperFactories
    ) {
        jdbi = Jdbi.create(dataSource);
        jdbi.clearMappings();

        jdbi.installPlugin(new SqlObjectPlugin());

        arguments.forEach(jdbi::registerArgument);
        mapperFactories.forEach(jdbi::registerColumnMapper);
        mappers.forEach(jdbi::registerColumnMapper);

        // ...

        // Jdbi instance fine-tuned for my exact database and demands, without surprises and at my own responsibility

ハウブーダ？ たとえば、アクティブ化する必要のあるクラスのセットで初期化する必要があるSetObjectArgumentFactoryと、多くのデータ型のマッピングロジックのあらゆる種類のバリエーションを提供し、該当する場合はいくつかの構成可能な動作を提供できます。 みんな幸せ。 エンドユーザーの作業が必要ですが、jdbiが私が望んでいることと、データベースがサポートしていることを正確に実行していることを知っているのは良いことです。

すべてのデータベース、およびデータ型のサポートが異なるさまざまなバージョンのマッパーをプラグインに提供するのは面倒だと感じます。

多くのデータベースベンダー向けのプラグインが欲しいです。 データベースベンダーまたはそのJDBCドライバーの特異性にJdbiを適合させるために、データベースにいくつかのカスタマイズが必要/必要な場合は、それについてお聞きしたいと思います。 またはさらに良いことに、プルリクエストが必要です！ :)

データベースがTravisCIによって直接サポートされている場合はボーナスポイントがあり、実際にデータベースに対してテストを実行できます：

あなたの「白紙の状態」の提案に関して、私はマイナーな異議しかありません：

• 私はおそらく入れてしまうでしょうclearMappings()に直接メソッドをRowMappers 、 ColumnMappers 、 Arguments 、およびJdbiCollectors configのクラスの代わりにJdbi 、そして私はそれらにclear()という名前を付けます。
• 組み込みのマッパー、引数、コレクターを公開するのは少し躊躇しています。 それらのいくつかは、内部的なものであるため、私たちが回避する奇妙な名前やデザインを持っています。 APIの一部にする前に、それらをリファクタリングしたいと思うでしょう。
• 白紙の状態が本当に必要かどうか疑問に思っています。 Jdbiのすべてのレジストリクラスはlast-registered-winsアプローチを使用しているため、すぐに使用できる動作をオーバーライドすることが常に可能です。 その意味で、白紙の状態は少しやり過ぎだと感じます。

@ jdbi / Contributors他の誰かが量り込みたいですか？

選択したものの1つを登録するのを忘れた場合に備えて、デフォルトのマッパーを誤って使用しないように、白紙の状態のアイデアを含めました。 デフォルトのimplよりもNotImplementedExceptionが必要です。 ラストウィンは素晴らしいことですが、何も望まない場合に、どれを却下する必要があるかを知る方法はありません。

持っているのが痛いわけではありません。 人々がそのアプローチを望まない場合、明確なメソッドを呼び出す必要はなく、何も変わりません。 これは、デフォルトのない作業方法を好む人のためだけのものです。

既存のマッパーを公開するだけではいけないことに同意します。 クリーンスレートオプションを提供することを選択した場合、マッパーとバインダーを妥当なPluginチャンク、 PrimitivesPlugin 、 BoxedPrimitivesPlugin 、 CollectionsPluginなどにバンドルする必要があります。

次に、構成をまったく行わずに「ベース」jdbiの新しいファクトリを追加し、これを使用するように既存のファクトリを変更して、 WholeJdbiEnchiladaPluginを追加できます。

付加的に構築するのが難しい場合を示すことができない限り、私は「クリア」にいくらか反対しています-私にはコードの臭いのように感じます。

付加的に構築するのが難しい場合を示すことができない限り、私は「クリア」にいくらか反対しています-私にはコードの臭いのように感じます。

別のno-preconfigjdbiファクトリを追加する場合、それを追加的に構築することは難しくないので、clear（）は実際には必要ありません。

そうです、私たちはここで同意していると思います。私はclear()スタイルよりも新しい「クリーンな」ファクトリメソッドを追加するという好みを表現していました。

それで、これはみんなの問題を解決しますか？ 個人的には、この計画はかなりセクシーに聞こえると思います。

• Jdbiをデフォルトなしにします（ほとんどすべてに例外をスローします）
• 既存のすべてのマッパーとバインダー（およびtxハンドラーなど）をプラグインバンドル（および個別のクラス）としてプラグイン可能（ PrimitivesPlugin 、 BoxedPrimitivesPluginなど）にします。
• いくつかの代替実装を提供します（ UTCJavaTimePlugin vs LocalJavaTimePlugin vs ConvertJavaTimeToUtilDatePlugin 、 GetObjectMapper.forClasses(Class... cs) 、 SetObjectArgumentFactory.forClasses(Class... cs) 、 NullsToDefaultsPrimitivesPlugin vs NullThrowsExceptionPrimitivesPlugin ）そしてそれらを同じ方法で（プラグインでそして個別に）公開するので、人々は彼らが望むものだけを正確にとって、彼ら自身の完全に望ましいマッピングロジックを構成することができます。 不正なnullやタイムゾーンの欠落を処理するためのさまざまな戦略やその他の考えられる不一致など、ここで必要になる可能性のある多くのマッパー構成
• おそらくdb固有のバンドルプラグインを作成するので、人気のあるデータベースとバージョンを使用しているユーザーは、構成なしのJdbiから始めて、db（ HsqlDb2_4_0Plugin ）の既知の適切なマッピングスキームを1行でインストールできます。さまざまな戦略の構成オプション付き
• そして、現在のファクトリメソッドに現在の事前設定（ BuiltInGenericPreconfigurationPlugin ）と、設定なしのファクトリメソッドを実行させるだけで、すべての下位互換性を実現できます。

Jdbiをデフォルトなしにする

私はあまり強い意見はありませんが、これはすべてユーザーの観点からは非常に複雑に聞こえます。 ユーザーは、使用するタイプに対して可能なさまざまなマッピングを理解し、適切なマッピングを選択する必要があります。 これは、特にテンポラルが機能している場合は困難です。可能なさまざまなオプションを理解することは実際には簡単ではありません。

ユーザーは、使用するタイプに対して可能なさまざまなマッピングを理解し、適切なマッピングを選択する必要があります。

いいえ、彼らが望む場合に限ります。 既存のファクトリメソッドは、現在とまったく同じプリインストールされたマッパーを使用してJdbiインスタンスを出力し続けます。 さらにDIY構成ファクトリメソッドを取得します。それらを選択する人は、マッピングの親密さを理解する必要があります。 DIYインスタンスを取得し、 YourDbAndVersionPluginをインストールして、それが何をするにしてもロールバックする途中もあります。 私の長い説明は、ベースラインではなく、主にjdbiの内部と高度な使用法でした。

TLDR：あなたはまだJdbi.create(dataSource)をすることができます、そしてあなたはあなたがまだ与えていないそれについての追加のフーツを与える必要はありません。 他の誰かがJdbi.createBlank(dataSource).install(x).install(y).install(z)...選択するだけです

私は参加していますが、既存の工場を廃止する必要はないと思いますが、「箱から出してすぐに使える」動作はかなり良いので、ほとんどのユーザーは引き続きそれを使用すると思います。

けっこうだ

@TheRealMarnesこの会話全体は、JDBCで直接サポートされていないJSR-310データ型を扱うことから始まりました。

誤ったjava.timeマッパーと引数を削除し、組み込みではなくプラグインに入れることについてはコンセンサスがあると思います。

それでもそれを追求したいですか？

java.timeのものだけですか？ JavaTimePlugin？

はい、java.time型専用のプラグインですが、@ findepiで説明されて

SimplisticJavaTimePlugin ？

私の他のPRが世話をするまでこれで待っています...それは同時に少し多すぎます。