どうも、みむらです。
しばらく記事を書かない間に、新暦が発表され、
そして私も会社が変わってしまいました。
最近はアプリ診断員にジョブチェンジしました。
IDA さんが友達です。
特に最近は iOS アプリを見ているので、
フォレンジックネタとか iOS に関するセキュリティ診断ネタであれば、
凄く話に乗れると思います。
それ以外には、Unity のアプリとか (lib2cpp の読み解きとか)
Windows ならユーザランドからカーネルランドまで。お話まってます。
閑話休題。
新暦と言えば、やはり新暦対応でしょう。
私も新暦が発表された直後から「なんとしても対応しよう」と遊んでました。
などなど。
今回は、もし「令和じゃない元号にします」と発表があった際に
素早く手持ちの環境を自己責任において対応させられるように（要出典）
Windows と Linux の対応の仕組みを見ておこう、とそういうテーマです。
Windows 側での対応
Windows の場合はレジストリキーを追加します。
（注：本修正を実施した事によりご利用中のプログラムに不具合が発生しても本サイトは責任を負いかねますと共に、くれぐれもプログラムの製造元へ連絡されませんようお願い致します）
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras 以下に
年号情報が詰まっていますので
REG_SZ 型にて
キー名：”<開始年> <開始月> <開始日>”
値：”<フル読み>_<代表する一文字>_<英語表記>_<英語短縮表記>”
のフォーマットにてキーを生成すれば OK のようです。
この値を設定すると、
この値を参照しているプログラムの処理系であれば
基本的に新年号に対応出来るようになります。
Linux (glibc) での対応
Linux の場合は locale ファイルを修正します。
（注：本修正を実施した事によりご利用中のプログラムに不具合が発生しても本サイトは責任を負いかねますと共に、くれぐれもプログラムの製造元へ連絡されませんようお願い致します）
locales ファイルは下記のパスに保存されています。
(Arch Linux, CentOS 7 にて確認)
/usr/share/i18n/locales/ja_JP
修正するのは、”era” の部分。
「○○元年」（+1 で始まるレコード）と「○○年」（+2 で始まるレコード）
を用いて年号の変換を行います。
そして年号は UTF-16BE の順番で書いていきます。
できあがった例は次の通り
1つめの “+:1:2019//05//01:2019//12//31:<U4EE4><U548C>:%EC<U5143><U5E74> は
2019年5月1日～2019年12月31日までを「令和(<4EE4><548C>) 元年(<5143><5E74>)」 と
表記するというもの。
2つめの “+:1:2020//01//01:+*:<U4EE4><U548C>:%EC%Ey<U5E74> は
2020年1月1日以降を「令和(<4EE4><548C>) %Ey(+2)年(<5E74>)」 と
表記するというものになります。
ですので上記のような ja_JP ファイルを作成し、locale-gen をすると
下記のように新暦に対応することができます。
最後に。
Windows や Linux のシステムがかなり柔軟に新暦対応させられる作りになっていることはおわかりいただけたかと思います。
ただ、これは一人のソフトウェア作者としてのコメントではありますが
全てのプラットフォームが上記で挙げたような簡単な方法で
すぐ対応出来るようになっているわけではありません。
また、上記のようなレジストリキーやファイルを参照するものであっても
（平成）31年から（令和）1年へ変わるわけですので
エラーが発生するシステムも十二分に考えられます。
ですので上記の方法で対応ができ、
ご利用のソフトウェアで問題なく稼働した場合でも
これは運が良かったという程度にお考えいただき、
ベンダーの正式対応を基本的にはお待ちいただくようにしてください。
上記のリスクにご理解いただけるかたで、新しいものに楽しみを感じるかたは
ぜひ自己責任において新暦対応を一足お先にお試しくださいませ。
なお、それによりデータ破損等が発生しても当方では責任を負いかねます。
・・というわけで。であであー。