結局、元号が変わったら何をしなくてはいけないのか
職業プログラマである故に、来年（２０１９年）５月１日の改元に備えた対応はそこそこ面倒です。
この記事は、その過程に仕事で調べたことの覚書です。
本当はQiitaとかに描きたかったのですが、
如何せん独自解釈によるものが多いので個人ブログに記載。
実装を行う場合は十分に検証をしてください。
元号そのものについて
いつから元号が変わるのか
冒頭で「２０１９年５月１日」って自分で云ったじゃんとか突っ込まない。
この記事を書いている時点ではあくまで
「『２０１９年５月１日』に改元する方針となった」というだけで
実際にはきちんと政令が出ているわけではない。
これは、元号を定義している法律「元号法」に明記されていることだ。
元号法をここに公布する。 （略）元号法
１ 元号は、政令で定める。 ２ 元号は、皇位の継承があつた場合に限り改める。附 則
１ この法律は、公布の日から施行する。 ２ 昭和の元号は、本則第一項に基づき定められたものとする。
元号法は１９７９年、つまり昭和時代に施行された法律で、
改元を定めた政令は「平成」への改元を行った１９８９年に１度のみ公布されている。
それが以下の「昭和６４年政令第１号」通称「元号を改める政令」である。
元号を改める政令をここに公布する。 （略）元号を改める政令
内閣は、元号法（昭和五十四年法律第四十三号）第一項の規定に基づき、この政令を制定する。 元号を平成に改める。附則
この政令は、公布の日の翌日から施行する。
公布の日の翌日から施行する、これほど厄介なものはない。
施行とは法令が効力を発することであり、逆に言えばではあるが施行当日まで法令に効力がない。
つまり「２０１９年５月１日」から新元号になるとわかっている今、
仮に元号も確定していたとしても、
「２０１９年５月１日」を迎えていない今日にとって、
「２０１９年５月１日」は「平成」であり、「新元号」ではない。
そして、「２０１９年５月１日」午前０時になると法令が試行されるので途端に「新元号」になる。
以上の通り解釈ができる。
はい、厄介（決めつけ）
例えこの通りだとしても、現実問題としてカレンダーを先に「新元号」に書き換えたところで
業務に問題が生じるとは到底思えないが、法令を厳密に守ってプログラムを組む必要が生じた場合
いやなことになりそうなので頭の片隅にはおいておきたい。
2019年1月2日_追記
４月１日に新元号が発表されると確定しました。エイプリルフールかな？
WindowsOSの定例アップデートが４月９日～１０日（第２火曜日）であることに合わせた発表だと思われます。
Microsoftには忖度するのに我々日本のプログラマには配慮しないのかよと思ったのは内緒。
2019年2月13日_追記
先日見た時には気が付いてなかったのですが
「元号を切り替える政令の施行日は５月１日とする」と書いてますね
上記の論理があってるような気がしますね。
改元後の「平成」の扱いについて
「既に作成されている文書についてはどうなるのか」という疑問がある。
これについては東京都杉並区の通知に以下のようなものがあった。
改元に伴う文書の取扱いについて（通知） 昭和64年１月７日63杉総総発第601号 （略） 改元に伴う文書の取扱いについて １ 新元号の使用等 公的機関の事務については、従来から原則として元号を使用しており、昭和の元号で表示されているものについては、新元号による表示に改めるものとする。 （略） ２ 旧元号による表記の効力 現行の条例、規則及び規程等のほか既に施行した契約書、許可証、証明書等の文書で改元期日以後の日を旧元号（昭和）により表示しているものについては、元号が改められることによっても、その法律上の効果が変わることはないので、有効なものとして取り扱うものとし、旧元号によって特定された日を新元号による応当日に読み替えて適用するものとする。 （略） ６ その他 旧元号の印字されている文書については、大量に在庫があるもの、その他特に理由のあるものを除き、早い機会に新元号により表示されているものに改め、使用するものとする。
２項の通り、旧年号（ここでは昭和）を使用しても問題ないようだ。
が、性急に対応する必要はあるようだ。
もちろんこれについては各市区町村や企業によって異なったり、
新元号への改元では、平成への改元とＩＴ事情が異なるとして該当するとは限らないが、
一応の参考。
ちなみに法令のところどころに記載されている「昭和６４年」などの表記は、
「平成」へ置き換えを行っていったらしい。
「官報情報検索サービス」（ https://search.npb.go.jp/kanpou/ ）で適当な日付を指定して、「元号を改める政令」、または「改め」「平成（元年）」「昭和64年」「昭和六十四年」「昭和65年」「昭和六十五年」（以下続く）等のキーワードの組み合わせにより検索すると、条文中の「昭和」を「平成」に改めるという内容の法令が見つかります。以下に該当箇所を引用して例示します。 （略） （例） （略） 『官報』平成1年（1989年）3月31日 特別号外 第7号 法律 「法律 第十四号 地方税法の一部を改正する法律」 「第七百条の二十七 道府県は、軽油引取税の取締り又は保全に関し、他の道府県と緊密な連絡を保ち、相互に協力しなければならない。 （中略） 附則第九条第一項中「昭和六十四年四月一日から昭和六十五年三月三十一日まで」を「平成元年四月一日から平成二年三月三十一日まで」に改める。」
新元号「１年」は「元年」と表記するべきなのか
あまり見ない話題ということはみんな気にしていないのかなと思える疑問。
生年月日、「１年」ではなく「元年」と書いても通りますし。
「元年」って書かなかったことにより書類選考で落ちたとかいう馬鹿な噂話も聞きます。
これについても、前項で参照した東京都杉並区の通知に以下のようなものがあった。
改元に伴う文書の取扱いについて（通知） 昭和64年１月７日63杉総総発第601号 （略） 改元に伴う文書の取扱いについて １ 新元号の使用等 公的機関の事務については、従来から原則として元号を使用しており、昭和の元号で表示されているものについては、新元号による表示に改めるものとする。 この場合に、改元期日である１月８日以後の公文書等に使用する本年の呼び方については「平成元年」とし、本年４月１日から来年３月末日までの会計年度の呼び方については「平成元年度」とする。 （略） ５ 訂正の方法等 (１) 旧元号（昭和又は昭）の印字されている文書（通知書・各種様式に定めるもの等）については、旧元号を抹消し新元号（平成又は平）を記載して使用する。 （略） (３) 年月日を省略して記号的に表示する場合は、「元・１・８」のようにすることを原則とするが、これが困難な場合は、次のように表記して差し支えないものとする。 ※ ① レジスター等の使用に当たり「元」の文字を表示することが不可能な場合 ② 領収印等のゴム印を使用する場合は、改製されるまでの間 〔例〕 64.１.８ → １.１.８
システムとして入出力ができない仕組みになってしまっていない限り、
やはり新元号「元年」と記載するのが原則のようだ。（あくまで平成元年時の場合）
いやー、今やってる仕事の帳票できねーわやべーなー（棒
４月始まりの年度表記（会計年度）
これについては項目を設けたものの自明で、「平成３１年度」、
５月以降から始まる場合は「新元号元年度」となるだろう。
年度始まり時点の年にあわせるのが通例だからである。
（実際、所属していた会社では１０月が年度始まりで、
実際の年ー１年度という表記になりややこしかった）
この表記で問題になるのは、年度末時点の年を使用する「米穀年度」なんだけど、
平成元年度の資料が見つからず調査断念。
詳細御存じな方は是非コメントか、wikipediaに追記をお願いしたい。
Windowsでの扱いについて
文字コード上でのリガチャー（合字）の扱い
「明治、大正、昭和、平成」の元号にはそれぞれ「㍾、㍽、㍼、㍻」というリガチャーが存在する。
そしてこの度の改元でも、Unicodeでリガチャーが作られることとなった。
Unicode Consortiumは9月6日(米国時間)、「The Unicode Blog: New Japanese Era」において、2019年5月1日からの適用が予定されている日本の新しい元号をサポートするため、新しい元号記号のコードポイントとしてあらかじめ「U+32FF」を予約したと発表した。 元号が発表されたら、U+32FFのキャラクタ名、デコンポジション、代表的なグリフを含んだバージョン12.1のドットリリースを実施すると説明している。
ではWindowsで「シフトＪＩＳ」に相当する、
「Microsoft CodePage 932（CP932）」はどうなるのかという話だが、対応しないらしい。
そもそもCP932は、すこし複雑な経緯で制定された文字コード*1であるらしく、
１９９２年にすでに仕様凍結されたらしい。
このスタンスを変えるつもりはないらしく、CP932には新元号のリガチャーは登録されない。
歴史的経緯についてはwikipediaの各ページのほうが詳しいのでそちらを参考。
Microsoftコードページ932 - Wikipedia
ちなみに「㍻」というリガチャーがJISに登録されたのは、
2000年に制定された「JIS X 0213」が最初らしく、
しかも「CP932」に登録された「NEC特殊文字」から逆輸入されたものなんだとか。
Windowsの時計に新元号を適応する
今年（2018年）4月30日に配信された「Windows 10 April 2018 Update」にて、
Windows10では新元号への暫定対応が行われたようです。
とはいえレジストリ*2に年表として保持しているだけみたいなので、
何らかの原因でアップデータが取れなくてもオフラインで追加できるみたいですね。
詳細は下記が分かりやすいです。
ちなみに定義の削除方法について、公式のフォーラムで紹介されている。
（とはいえただレジストリから削除すればいいだけなんだけど）
Windows 10 Version 1803 における新元号の仮定義の削除について – Japan New Era Name Support Blog
エクセル（MS Office）での扱い
最近（１１月ごろ）に補正バッチが配布されていたのですが、どうもOffice2010のみに不具合があったらしいです。
なお、Officeについても先項の通りレジストリを使用するようです。
プログラミング言語
Java
Javaでは「SimpleDateFormat」クラスを使用して和暦書式に日付を出力できる。
OracleJDKでは新元号に対して対応するのかどうかは分からない（調べたけどみつからなかった）が、
少なくともすでに無償サポートの終了しているJava 8までは元号対応はないのでは？と思われます。*3
手動で対応する場合は、以下の２通りが挙げられます。
方法１．プロパティを設定
この方法はJava9以降ではできないそうです。
Javaで用意されている、calendars.propertiesに新元号の情報を追加するようです。
http://blue-one-show.com/2018/09/01/java%E3%81%AE%E6%96%B0%E5%85%83%E5%8F%B7%E5%88%87%E3%82%8A%E6%9B%BF%E3%81%88%E5%AF%BE%E5%BF%9C/blue-one-show.com
しかしこの方法、
配布しないならばともかく配布アプリケーションの場合問題ないのか？という疑問がある。*4
方法２．起動引数
こっちの方法はJava 8以前でも使えるらしいですが。
Javaアプリケーション起動時のオプションとして、
「jdk.calendar.japanese.supplemental.era」を設定すると新しい元号が使用できるようになるらしい。
Java9 新元号(年号)を追加 – SOFTEMCOM Developers Blog
.NET Framework
Windowsのレジストリ内に存在する年表を参照しているため、
先に紹介しているレジストリを修正すれば、新元号に対応できる。
というのは、.NET Framework 4 以降のバージョンに限る話で、
.NET Framework 3.5までは、同様の対応を行う予定なんだそうです。*5
詳細については以下の記事を参照。
.NET Framework の新元号対応予定について – Japan New Era Name Support Blog
2019年1月12日 追記
Handling a new era in the Japanese calendar in .NET | .NET Blog
１１月１４日付でＭＳから「元年」表記追加するよって追記されていました。
このタイミングで「新元号１年」を「新元号元年」と変換するとかもうふざけんなと思わざるを得ませんが前述の「元年」表記の問題は.NETに限っては解決しそうです。
JavaScript
以下のようなスクリプトを入れると年号が表示されます、実は。
new Date(2010, 0, 8).toLocaleDateString("ja-JP-u-ca-japanese", {era: 'short'})
JavaScriptは各ブラウザ毎に処理エンジンが異なってくるので、
ChromeやEdgeといったブラウザが対応してくれるのを待つしかない。
まぁ最近のブラウザは自動更新機能が標準搭載だから、
勝手に対応されるのではと思ってます。
問題になるのはnode.jsなどブラウザ以外のエンジンでしょうか。
ソフトウェア
Oracle（データベース）
Oracle公式としての対応状況については「My Oracle Support」（Oracleのサポート記事）にて公開されるとみられている（アカウント登録が必要）
手動でも対応は可能で、日本の暦を管理している「lxecalji.nlb」というバイナリファイルが存在しているらしく、ここに新しい元号を追加すれば新元号が使用できます。
問題は、どうやってもOracle自体の再起動が必要なようで、DBサーバーを一時的に止めざる得ないことでしょうか。
やり方については以下の記事が詳しい。
2019年2月1日 追記
記事を書いた時点では方法について何も考えていなかったのですが、
いっそ和暦変換用のストアドプロシージャを作成し、
和暦変換を行っている「TO_DATE」（文字列→日付）や「TO_CHAR」（日付→文字列）を
作成したプロシージャに置換してしまうという手があります。
たぶん、SQLを差し替えるだけで済むようなシステムならこのほうが対応は早いかもしれない。
以下、気になる元号対応だあったら随時更新する予定。
*1:60～80年代に制定、更新されたJIS X 0201とJIS X 0208、及び協力会社の文字コードを統合したもの。
*2:レジストリパス：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras
*3:有償サポートの場合、2025年まで受けられるらしいので何とも言えませんが
*4:杞憂？
*5:７月に対応する予定だったが、延期したらしい。同時に更新予定だった「昭和８０年」みたいに大きい日付の年号を正常処理する対応はできたらしいが。。。
