日付は和暦で見せる — 日付ピッカーと ngwFunc_SWHenkan

日付は、和暦で見せる

役所の書類は、日付を和暦で書く。「令和8年7月5日」のように。だからNGWのあらゆる日付欄も、和暦で表示できなければならない。

単純な整形に見えて、和暦変換は制度の壁だ。改元があるから境界の日付で元号が変わる。表記も一通りではない——「令和」「令」「R」「5」。ゼロ埋めするか、区切りは「年月日」か「/」か「.」か。これを画面ごとに自前で書いていたら、表記はばらつき、改元のたびに全数改修という悪夢になる。

NGWは、この和暦変換をたったひとつの関数 ngwFunc_SWHenkan（西暦→和暦）に集約している。そして日付入力のUIは、その上に立つ ngwFunc_MakeDatePickerJ が引き受ける。順に見ていく。

OBJ TYPEを「DATE」にするだけ

前回のCreateDBWebの続きだ。NGWT_SAMPLE に日付の列をひとつ足し、その画面オブジェクト（OBJ TYPE）を「DATE」にする。

CreateDBWebでNGWT_SAMPLE_DATE列をDATE型・OBJ TYPE=DATEとして定義した画面

NGWT_SAMPLEに `NGWT_SAMPLE_DATE`（型DATE・OBJ TYPE=DATE）を追加。列のオブジェクトを「DATE」にするだけで、日付ピッカーが生成される。

これだけで、CreateDBWeb はその列に ngwFunc_MakeDatePickerJ を使った日付フィールドを生成する。人は日付ピッカーのコードも、和暦のことも書かない。

出てくるのは、和暦の日付ピッカー

生成された画面で日付欄を開くと、こうなる。

生成された和暦の日付ピッカー。値は「令和8年7月5日」、カレンダーに令和8年の年セレクタ

生成された「サンプル日付」欄。入力値は和暦「令和8年7月5日」で表示され、カレンダーの上部には元号つきの年（令和8年）と月のセレクタが並ぶ。

ngwFunc_MakeDatePickerJ の中身はこうだ。まず表示用に、値を ngwFunc_SWHenkan($DateVal, _SWH_TODAY_)（や _SWH_SIMPLE_）で和暦へ変換する。そこへ jQuery の datepicker を載せ、ユーザーが日付を選ぶと、クライアント側の fncDatePickerConvertWareki() が選択日をまた和暦へ変換して表示欄に戻す。データは西暦で保持し、人には和暦で見せる——その橋渡しを一手にやっている。

和暦変換の本体：ngwFunc_SWHenkan

その中核が ngwFunc_SWHenkan だ。呼び方は一行、だが4つのフラグで和暦表記のあらゆる組み合わせを出し分ける。

$wDate = ngwFunc_SWHenkan($sDate, $hMode, $gMode, $zMode, $sep);

$hMode（変換モード） … 年月日 / 年だけ / 年月 / 単純（日付が無くてもTODAYにしない）。定数 _SWH_TODAY_ / _SWH_NEN_ / _SWH_YM_ / _SWH_SIMPLE_。
$gMode（元号表現） … 令和 / 令 / R / 5。フル表記・1文字・アルファベット・元号番号を選べる。
$zMode（前ゼロ） … 前ゼロ なし / あり / 前スペース。
$sep（区切り文字） … 年月日 / / / .。

つまり同じ日付が、帳票では「令和8年7月5日」、狭い欄では「R8.7.5」、CSVでは「R08/07/05」——と、呼ぶ側がフラグを変えるだけで出し分けられる。実装は、ひとつ。

なぜひとつに集約するのか

理由は、ひとつ挙げれば十分だ。改元である。

元号が変わるとき（平成から令和へ変わったように）、境界の判定と新元号の追加を直すのは、ngwFunc_SWHenkan 一箇所だけでいい。すると全画面・全帳票・全ての日付ピッカーが、一斉に新元号に対応する。もし各所で自前の和暦変換を書いていたら、改元のたびにシステム中を洗い出して全数改修——考えるだけで気が遠くなる。

日付という制度依存の塊を、ひとつの関数に閉じ込めておく。これは唯一の基準の、いちばん効く実例だ。FullCalendarの記事で「日付入力の日本語化をひとつの関数に集約した」と書いたが、その関数こそ、この ngwFunc_SWHenkan とその上の ngwFunc_MakeDatePickerJ である。

徹夜が、1分になった

じつは、この「元号を一箇所に集約する」という発想には、はっきりした原点がある。

昭和から平成に変わったとき、私は汎用機の前で、元号変換の作業を徹夜でやっていた。あちこちに散らばった日付処理をひとつずつ直して回る、終わりの見えない夜だった。あの晩に骨身へ染みたのだ——元号は、標準化しておかなければならない、と。いまのこの設計は、その記憶から生まれている。

余談をひとつ。そのとき、変換結果を「平成1年」で返してしまい、数日後に「平成元年」へ直した。和暦の初年は「1年」ではなく「元年」と書く——制度というのは、こういう細部で必ず一杯食わせてくる（もちろん今の ngwFunc_SWHenkan は、そこも心得ている）。

そして時は流れ、平成から令和へ。改元にあたって私がやったのは、NGWT_CONSTANT に新元号を1行足すこと。それだけだった。所要、わずか1分ほど。かつて徹夜で駆けずり回った作業が、たった1行のデータ追加で終わったのだ。定数をDBに置く仕組みと、和暦変換の集約とが、きれいに噛み合った瞬間だった。

徹夜が、1分になる。集約とは、突き詰めればそういうことだ。

AIとの協働作業での学び

和暦は、日本の行政システムが必ず通る制度の壁だ。単純な日付整形に見えて、改元・表記ゆれ・境界という制度の重みが詰まっている。それをひとつの関数と4つのフラグに畳んだから、改元が来ても慌てず、どの画面も同じ和暦で揃う。

そして CreateDBWeb が「DATE」と定義するだけでこの仕組みを吐くから、開発者は和暦のことを一切考えずに済む。制度依存ほど一箇所に閉じ込め、その一箇所を生成で配る——地味だが、これが「10年、改元をまたいで動き続ける」ということの実体だ。