系で同じ現象になっているようです)...MySQLのJDBCドライバーは、ミリ秒がないDATETIMEに対して何か特別な処理をするわけでもなく、ミリ秒があるDATETIMEに対する処理と同じ扱いをするようです。登録時の四捨五入のジレンマそのギャップでちょっと困ることがあるかもしれません。日時を埋めて登録するとき、そのままだと四捨五入で次の日になってしまいます。Java側でミリ秒を切り取ればOKですが、そこまでDBの挙動を意識した処理が業務ロジックに入ってしまいますし、どのみち抜けると思います。既存DBだとそうもいかないでしょう。検索時の考慮されジレンマselectのwhere句の方は、さらに困る事態に。23:59:59.001)これで、ヒットしません。「一秒の隙」で何もヒットしない瞬間があるということです。処理がエラーで落ちてしまう可能性があります。現在日時を取得するとどうしてもミリ秒は入ります。現在日時の取得インターフェースでミリ秒を削るか?と言ったら、ミリ秒が必要なこともあるでしょうから、それはそれで将来への負債へとなりかねません。「終了直後の最初の瞬間」にすればOKですが、(つまり、次の期間のBEGINと同じ日時にする)既存DBではそうもいかないでしょう。他の要因でもあったりするでしょうから。解決というか回避するオプションを導入しました。引数で指定された日時データのミリ秒を削るというものです。昔のMySQLのJDBCドライバーがやっていたことを、ConditionBeanが再現します。設定して自動生成し直すと、そのような挙動になります。この問題をすでに抱えている、もしくは、これを読んで問題があることがわかった方は、こちらのオプションを検討してみてください。...ちなみに、ミリ秒がないDATETIMEに対してのみの処理になっています。論理的には「0.1秒の隙」が発生する可能性があります。そもそもミリ秒の最初の一桁だけのDATETIMEを作ることはほとんどないでしょう、ということで。...こちら実現方法はちょっと大変でした。「DATETIMEのミリ秒ありなし」を判断しないといけません。ミリ秒ありのDATETIMEに対して何か余計なことをやってはいけないので、ちゃんと判断しないといけません。JDBCドライバーのメタデータから、DATETIMEのミリ秒精度を取得することができないのです。DatabaseMetaData@getColumns()の項目にないのです。