OpenDolphin日記

---

Javaにおける日付・時刻APIの歴史は、設計の失敗と、それを乗り越えるための試行錯誤の歴史である (by ChatGPT)

---

Java の日時処理は、C言語の時刻APIの影響を色濃く受けた java.util.Date から始まった。その後、より柔軟に扱うための抽象クラス Calendar が登場し、その代表的な実装として GregorianCalendar が使われるようになった。自分が OpenDolphin をいじり始めたのは Java 1.5 時代であり、日時はこれらのAPIで扱っていた。しかし、このAPIには月が 0 から始まるという強力な罠があった。

new GregorianCalendar(2026, 8, 17) // 2026年9月17日

そして歴史は進み、ついに Java 8 で JSR 310 として java.time が導入された。用途ごとに明確な型が用意され、基本的にイミュータブルである。日付・時刻処理を、ようやく安心して書ける時代が来た。

とはいえ、うちの OpenDolphin での JSR 310 への移行は、そう簡単なものではなかった。Date、GregorianCalendar、java.time が複雑に同居、さらに infomodel には、イベントを保持できる独自の日付システムである SimpleDate もある。変換処理はあちこちに散在しており、下手に直せば日時の境界条件で壊れかねない。まさに恐ろしい混沌であり、これまでは見て見ないふりをしてやり過ごしてきた。

それでも今回、意を決して java.time（JSR 310）へ統一するリファクタリングを決行した。

使用箇所は想像以上に多かった。引数、戻り値、DBとの変換、画面表示、テストデータまで、日付はアプリケーションのあらゆる場所に入り込んでいる。型が違えばコンパイルエラーで止まるため、そこを手がかりに一つずつ型を書き換え、移行を進めていった。

最後までしぶとく残ったのが、month + 1 問題である。Calendar の月は0始まりなので、実際の月にあわせるために、+ 1 や - 1 が、随所に入り込んでいた。これはコンパイルエラーでは検出できないため、厄介だった。そして、受診日検索に残っていた最後の1個を退治したとき、ようやくすべての日付処理を JSR 310 へ統一できた。

結構な手間であったのだが、機能が追加されたわけではなく、使っていて意識されるところははない。しかし、今後の日付処理を安心して変更できる土台ができたことは大きい。もう月の値を見て、「これ、0始まりだっけ？」と身構えずに済むようになった。