Windows 10 April 2018 Updateで追加された和暦のレジストリィの話
追記 (2019/4/2)
次の元号として令和が発表されましたので、令和のレジストリィを追加するPowerShell Scriptを書きました
Windowsに令和のレジストリィを追加するPowerShell - 木俣ロバート久の覚書 - Hatena Blog
追記 (2018/6/25)
.NET Framework の新元号対応予定について – Japan New Era Name Support Blogにて.NETの仕様変更が発表されました
アメリカ時間のからupdateが提供が開始され.NETの挙動が変わるため、本記事の内容と異なる状態となる見込みですのでご注意ください
各所既報の通り Windows 10 のWindows 10 April 2018 Update (1803) で元号のレジストリィに、に改元予定の仮データが入りました
例によってPowerShellで取ってみます
PS >Get-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras';Hive: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\JapaneseName Property
Eras 1868 01 01 : 明治_明_Meiji_M 1912 07 30 : 大正_大_Taisho_T 1926 12 25 : 昭和_昭_Showa_S 1989 01 08 : 平成_平_Heisei_H 2019 05 01 : ？？_？_??????_?
ちなみに、"?" や "？" は文字化けの類ではなく、Unicode でいう 'QUESTION MARK' (U+003F) や 'FULLWIDTH QUESTION MARK' (U+FF1F) の文字が仮データとして入っています
あくまで仮データではあるのですが "必ず漢字かアルファベット" だと思い込んでレジストリィから取得した値をエスケープせずに正規表現に突っ込むと本番では起こらない筈のエラーが出たり意図しない挙動になります (なった)
また、例えばファイルを和暦の文字列で "H30.05.28" のようにしているシステム場合、現時点でレジストリィから値を取得してファイル名を作ると 2019年5月1日のファイルの名前が "?1.05.01" となりファイル名として "?" が使えないためエラーになったりするかも知れないので仮データならではの注意も必要になります
更に、平成31までの日付の文字列は DateTime型に変換できていますが、平成32年以降の日付は変換できなくなっています
PS >'平成31年12月31日' -AS [DateTime]; 2019年12月31日 0:00:00PS >('平成32年1月1日' -AS [DateTime]) -Eq $null; # -AS で変換しているので変換できなかった場合はNullになる True
また、明治を1、大正を2として明治以降のその時の元号のカウントを返すGetEraも2019年5月1日以降は5を返すようになっています
JapaneseCalendar.GetEra メソッド (DateTime) (System.Globalization).aspx)
PS >[System.Globalization.JapaneseCalendar]::New().GetEra([DateTime]'2019/4/30'); 4PS >[System.Globalization.JapaneseCalendar]::New().GetEra([DateTime]'2019/5/1'); 5
以上は.NETの話で、独自実装されたものは勿論それぞれがレジストリィを参照しているかどうかの実装次第ですし、例えばExcelのVBAの場合、 では新元号には対応しておらず、平成32年以降の日付も使えている状態です
例えばセル内のデータを 2030/5/1としてセルの書式設定で元号表記にすればH42.5.1となります
以下のようなマクロで処理した場合も平成のまま処理が行われます
Function ChangeJapanese(ByVal DateString As String) As String
ChangeJapanese = Format(DateString, "ggge年m月d日")
End Function
Function ChangeChristian(ByVal DateString As String) As String
ChangeChristian = CDate(DateString)
End Function
- セル内の式:
=ChangeJapanese("2020/5/1") - セルに返却される値: 平成32年5月1日
- セル内の式:
=ChangeChristian("H40/1/1") - セルに返却される値: 2028/01/01
というわけでプログラマ各位としては和暦文字列と日付データの変換個所やGetEraの結果が5でも問題ないか (例えばSwichに入れた結果 Default で未知の元号扱いにしていないか……実際現時点では未知の元号なので正しいといえば正しいのですが) などを確認しておいた方が無難かもしれません
もし改元が江戸以前のように数年に1回程度発生してればシステム側としてももっとノウハウがたまっているかと思うのですが、今回は30年ぶり、次回はいつになるか分からないので今回できるだけ記録を残したいなあ、と思っている次第です (改元の契機を考えるなら次の元号も長く続いた方が嬉しいのですが)
