システム上の日付は、西暦でもたないとダメと断言してもいいでしょう。
とはいうものの、元号法が生きているので、画面上、帳票上は和暦を明記する必要があります。UI段階で変換すれば十分でしょう。
では元号はどこで処理するか、FrameWorkライブラリーやRDのミドルウェアーの元号モジュールで処理をしているケースが多いかと思います。いつになるか不明ですが、改元は必ず来ます。すぐ、ミドルウェアーが対応してくれればいいのですが、保証はありません。元号処理は自前で準備するのがGOODです。ではミドルウェアーの元号処理は信頼度はどうなのか。
信頼度の線引きにもよるので、一概に言えません。いまだに昭和80年など昭和換算で処理しているシステムもあるわけですので。
DateTime.ParseExact(r, "ggy年M月d日", culture); で和暦の整合性をチェックできます。
昭和65年1月1日はNG...昭和の終了年超は押さえているようです。
昭和64年12月31日はOK...改元日は押さえてないのか。
平成1年1月1日 はOK.....改元日は押さえてないのか。
昭和1年1月1日はOK......改元日は押さえてないのか。
明治1年1月1日はNG......?なんでNG?
明治1年10月1日はOK.....?なんでOK?
境界点は明治1年9月8日でしてた。 この日は、明治に改元された日です。 なんで、明治だけ、改元日が考慮されているの?
しかし、コンピュータ上はの9月8日は太陽暦で処理されている。 明治1年9月8日改元は旧暦で行われているので、一致しません。
太陽歴に変わったのは、明治5年12月3日です。この時は、12月2日の次の日がいきなり、明治6年1月1日になりました。(体験はしてませんよ)つまり,12月は二日しか無かったのです。DateTime.ParseExact()は考慮されてませんでした。
12月を一ヶ月飛ばしたのは、公務員給与を一ヶ月不払い(5年度の支給分)になるので、予算的に助かった...という都市伝説があります。真偽は知りません。何を血迷ったか、そのとき古い太陽歴であるユリウス暦を採用したため、明治31年にグレゴリオ暦に切替直したようです。このときも、一週間、存在しない日があったそうです。
西洋でもグレゴリオ暦に切り替えるときに、西暦1582年10月4日の次の日を、10日ずらして、10月15日としています。
Oracleの日付関数はどのように処理しているのだろう。気になるところです。
今の暦でも3300年に1日のずれが生じるので閏日問題が残っているようです。地軸のズレで公転周期もずれるでしょうから、そこまで考慮しても意味は薄いのでしょうが。
暦といえば月名がありますが、10月なのにOctober といいますね。octは8であり、蛸はOctpus です。もとは年１０ヶ月制だった暦を12ヶ月制に移行にする際、時の皇帝の名前から、July,August が挿入され、「大の月でないとイヤだ」とゴテられた結果、7月・8月は大の月になり、その反動で、2月が二月が28日になったと伝えられています。
天文学と暦は合理的なものなのに、運用面では、人間的な部分が多くて、面白いですね。
昔の出来事の当日は何曜日だと算出するアプリがありますが、暦が考慮されているのだろうか。
もっとも、通常の業務アプリが大正以前の日付を扱うアプリは少ないと思います、資料管理や歴史研究アプリなら必要かも知れません。旧暦の誕生日の人の年齢計算が必要になったらどのように処理したらいいのだろう、換算テーブルで読み替えになるのかなぁ。作る局面はないでしょうが。