ことの発端
2019年2月13日のWindows uodateを適用すると、元号一文字表記が㍻などの合字に変更される問題が発生しました。
Microsoft、「KB4487044」適用で元号に不具合
Windows 10の2月の月例更新には元号関連の不具合がほぼ全ての場合バージョンに存在
しかし、マイクロソフト社は、以下のページにあるとおり、この問題を日付文字列のパースの問題であるという認識を示しました。
2019 年 2 月 13 日 — KB4487044 (OS ビルド 17763.316)
多くの方は、マイクロソフト社が不具合を認めたことで、「レジストリ値を元に戻すんだな」と理解したかもしれませんが、どこにも、合字に置き換わった事自体が問題だとは書かれていませんし、レジストリの値を戻す対応を予定しているとも書かれていません。
僕の勝手な想像
ここでは詳しいことを書くことは差し控えますが、僕の見聞きした範囲から判断すると、マイクロソフト社は、
「日付文字列をパースするAPIを修正する」
ことでこの問題に対応しようとしているような気がします。
つまり、レジストリの値は、
「平成_平_Heisei_H」
から、
「平成_㍻_Heisei_H」
に変更することが決定事項なのではないかと、僕は想像しています。これは、何もしなければ、かなり高い確率でそうなると思っています。
マイクロソフト社では、本来あるべき姿にしたのだからこの変更は正しい変更だと考えているのでしょう。たぶん...
でも、ほんとうに仕様変更してもいいのか？
例えば、カレンダー表示で曜日を3文字の省略形で表示しているアプリがあるとしましょう。
Windows Updateを適用したら、"Mon"が"Monday"に、 "Tue"が”Tuesday”に勝手に置き換わってしまったら、それは許されるのでしょうか？ 仮に、表示幅がこれまでと同じ幅で表示されたとしても、他社のアプリケーションの仕様をマイクロソフト社が勝手に変更してよいとは言えないと思います。
平が㍻になってしまうというのは、まさにこれと同じだと思うのです。マイクロソフト社が勝手にアプリの仕様を変更することが許されて良いとはとても思えません。
以前のマイクロソフト社は互換性を大切にしていて、APIの仕様変更に対しては、とても慎重な姿勢だったように思います。しかし、こと改元対応については、まったく互換性のことを無視しているように感じています。
合字を使うことのもう一つの問題点
4月には、新元号が発表されます。その時は、レジストリには、新元号に対応した合字のコードが書き込まれると思います。（そうならないことを願っていますが...)
しかし、4月1日には新元号の合字フォントは間に合わないはずです。その時に、新元号を表示するアプリケーションはどうなるのでしょうか？ 未来の日付を扱うアプリでは問題が起こります。
もしかしたら、5月1日にもフォントは間に合わないかもしれません。
MS明朝や、MSゴシックでアプリを作成していた場合はどうなるのでしょうか？ 特に印刷においては、このフォントを使っているアプリは多いのではないでしょうか？
MS明朝や、MSゴシックも合字に対応するんですね。勘違いしていました。
こういったことをマイクロソフト社が考えているのかも疑問です。「フォントが間に合わないんだから、空白表示でもしかたないよね」「今更、MS明朝やMSゴシックを使ってるアプリはほぼないよね」という、そんな考えだとは思いたくありませんが、APIの仕様を変更することでどんな影響がでるのかを真剣に考えている人がマイクロソフト社にいるのか、本当に心配です。
マイクロソフトさん、お願いです。.NET Frameworkの改元対応の方針がどうなっているのかを、きちんとした形で発表してください。もちろん日本語でお願います。
これを問題視しているのは少数派なのか
ネットなどをみても、今回の問題はそれほど大きな問題とはなっていないような気がします。
以前あった、'??' のエントリをレジストリに追加してしまった時も、それほど大きな問題にはなりませんでした。
これは何を意味しているかといえば、元号を扱う多くのアプリケーションは、.NET Frameworkのクラスを使わずに、独自実装しているということかなと思います。
つまり、マイクロソフトを信じて、.NET Frameworkを使い、元号対応しているソフトウェアはとても少ない。
それとも、平が㍻になることは、大した問題じゃないと、みんな思っているのでしょうか？
どうであれ、マイクロソフトを信じたエンジニアがバカを見るという、なんとも悲しい現実が...
なぜ、今なのか？
そもそも、なぜ、.NET FrameworkのAPIの仕様変更を、今やるのでしょうか？
多くの企業はすでに新元号への対応を終わらせており、あとは、新元号が発表されるのを待つだけなのではと思います。
しかし、.NET FrameworkのAPIが変更されるということは、再度、対応をやり直さないといけないということです。
元号の省略形を.NET Frameworkのクラスをつかって取得しているアプリケーションは、単に動作確認をするだけではなく、仕様をどうするかを再検討し、必要ならば、アプリケーションの修正を行わなくてはなりません。
自社開発のアプリケーションならばまだいいですが、そうでなければ、顧客の意向を確認しなければなりませんし、各省庁などが定めた書式の場合は勝手に変更することはできません。
今までの準備はいったいなんだったのでしょうか？
最悪、ユーザ側でレジストリの値を元に戻して、これまで通りの動きにするという対応が考えられますが、レジソトリの値が、平成_㍻_Heisei_Hに置き換わってしまわないという保証はどこにもありません。
僕たちはどうすべきなのか
僕は、あるルートを通じて、マイクロソフト社の改元対応の担当の方に、今回のレジソトリ変更はとても困るので元に戻してほしいという意見を出しましたが、果たして、真剣に取り合ってくれるのか心配です。
「ほかにはそんな意見は来ていないし、一人の開発者の意見なんか無視すればいいんじゃないの」とか「もう、本社が決めたことだから、これでいくしかないんだよ」ということになってしまうのではないかと危惧しています。
もし、これを読んでいる皆さんのなかで、㍻や㍼などの合字になることで問題になるような方がいれば、
- それぞれの方が持っているルートを使って、マイクロソフト社に働きかける。
- SNSなどで、意見を表明する
ということをやっていただけるとうれしいです。
また、僕がここに書いている情報は間違っている、ほんとうはこうだよ、という情報をお持ちのかたは、コメント等で是非お教えください。
最後に
思いつくまま、想像と勢いで書いてしまった部分があり、誤解を与える表現だったり、支離滅裂な部分があるかもしれませんが、ご容赦ください。
それと、これが心配性の僕の杞憂で終わってくれることを切に願っています。
追記 (2019/02/20)
書き忘れてましたが、レジストリを変えるのは別に良いんです。でも以下のAPIの動作は変えないでほしいということです。
DateTimeFormatInfo.GetAbbreviatedEraName
追記 (2019/02/22)
以下のURLから辿れる更新プログラムを適用すれば、レジソトリの値が元に戻るようです。
とりあえずは、一安心ですが、このupdateは緊急パッチ的なものだと思うので、公式的な発表(or説明)があるまでは、予断を許さない状況だと思われます。
2月のパッチでWindowsの元号処理や仮想マシンの復元に問題 ～Microsoftが修正版を公開
なお、最新版のWindows10 (ビルド1809)の更新プログラムは、まだ出ていません。
追記 (2019/02/23)
今回はAPIの仕様が変更されたことを問題視しているわけですが、「.NET Core3.0からは動作が変更されます」というような仕様変更ならば、そして、その理由に妥当性があるのならば、まあ、問題はないと思います。
我々開発者は対応するための時間的な余裕が与えられます。
しかし今回のは、知らないうちに仕様が変わってしまうのですから、それとはまったく問題の本質が異なっていると思うのです。
追記 (2019/03/15)
3月のWindows Updateでは、レジストリの値を合字に変更することはしていないようです。たぶん、このまま5月を迎えられそうです。いやー良かった。