未来日を和暦で扱うアプリは Windows 10 1803 で影響が出ないことを確認しましょう

和暦に関する Delphi/C++Builder 10.2.3 での話は 筑木が先日投稿した記事 の中でご説明しておりますが、Windows 10 の 2018年春のアップデートでは元号改正に伴う仮対応としてレジストリにプレースホルダの追加が予定されていることや、Delphi/C++Builderでの挙動を紹介しています。

しかし、Windows 10 1803 で追加されるレジストリの仮対応は、未来の日付を現時点で和暦で扱うアプリケーションで2019年5月1日以降の日付の西暦-和暦変換を行う場合に意図しない形での出力となります。このことが問題になるケースはおそらくはレアケースだろうと思うのですが、本記事ではこれについて補足的な説明をさせて頂くことにします。

和暦を扱うシステムが2019年5月1日以降の未来の日付を扱う場合は、暫定的にレジストリの修正が必要かもしれませんよ？

Windows 10 1803 でレジストリに追加されるレースホルダは "2019 05 01"="？？_？_??????_?" のように、2019年5月1日の改元日に対して仮設定を追加するものです。新しい元号は公示されていませんから ? で表記されているわけですね。このような設定は、現在の日付や過去の日付を西暦和暦変換する場合には当然ながら全く問題がありません。

しかしシステムが何らかの形で未来の日付を和暦で扱う場合に OS の機能で西暦 – 和暦変換を行っていると、Windows 10 1803 で追加される仮対応のプレースホルダによって和暦の元号が？で表記される状況が生じます。例えば2018年4月1日～2020年3月1日というような契約の日付を和暦変換して出力しようとすると、Windows 10 1803 とそれ以外のバージョンでは次のように結果が異なります。

これを簡易的に検証するには、PowerShell 上で以下のように実行してみます。

これは “2010年3月31日” という日付を和暦で表示する処理です。Windows 10 1709 までの環境なら、平成32年3月31日 と表示されているはずです。この和暦の日付は元号改正が行われていない現時点では正しい日付です。しかしお手元の環境が Windows 10 1803 相当の場合は ？？02年3月31日 のように出力されるはずです。ご利用中のアプリケーションが未来の和暦をOSの機能で生成している場合は同様の出力が行われてしまうことになります。

ですが、これはアプリケーション側のバグではなく、また開発ツールの問題で発生するわけでもありません。レジストリに追加された内容に基づく正しい動作です。

もしもこの挙動が問題となる場合には Windows 10 1803 で追加される予定の仮対応のプレースホルダを当面はレジストリから削除するなどの対処が必要です。より正確にいうと、新しい元号が公示されるまでは削除しておく必要があると思われます。

インハウス向けの場合は Windows 10 の Semi-Annual Channel（Targeted）を一般従業員向けに直ちに配布することはないでしょうから、Windows 10 1803 の適用は2018年夏以降に実施することになるとは思います。しかし将来の日付を和暦で扱うアプリケーションやシステムをお使いの場合は、プレースホルダの追加による影響を早めに確認しておきましょう。

では実際のアプリではどうやって確認すればよいでしょうか？

確認は下記のいずれかで実施可能です。

1. 現在ご利用中の Windows でレジストリに Windows 10 1803 で追加されるレジストリの仮設定を入れてみる
2. Windows 10 1803 でテストしたい場合は、本日（2018/4/24) 時点では Windows 10 Insider Program 向けの Build 17134.1 が利用可能

レジストリの操作に不安がなければ、1. が手間なく確認できて良いと思いますし、検証用の環境(仮想マシン含む）がある場合は Insider Preview をインストールして検証するほうが、より確実ですね。

なお、レジストリを書き換えての動作確認については過去記事 元号が改正された場合の西暦と和暦の相互変換について にて説明していますので、そちらも併せてお読みください。

2018年4月23日～5月4日までの月～金曜に毎日ブログを更新。Delphi / C++Builderに関する技術記事からエンジニアの日常まで、さまざまな話題を投稿します。お楽しみに！ 日本人スタッフブログを一覧表示できる、こちらのページをブックマークしてください。