『警告』新元号対応問題：2018年5月以降、"2020/10/10"を和暦で"？？2年10月10日" と表示されるような変更が行われます。

> うっかり文字としてデータベースなどに登録されると惨事を招きかねません。
> いくら日本政府の新元号の公開が遅いからといって、中途半端な修正は迷惑です。

そういう「文字列で登録されるシステム」では、今の環境だと「平成32年」で登録されると思いますが、正式な元号がレジストリに登録された後は、そのシステムは「平成32年」を日付として解釈できなくなります。

ゆえに、このレジストリの影響を受けるシステムかつ、文字列で登録してしまうシステムは、この修正があろうとなかろうと問題になるでしょう。

逆に言えば、平成32年をすでに登録してしまっているシステムを抱えている場合、この更新によって問題が見つかるとも言えます。
問題にぶつかってしまった場合はレジストリを一時的に削除する運用回避をしつつ、システム改修を早期に計画・実施して、正式な改元に備える必要があるでしょうね。

（中長期の期間を扱う予定表のようなもの、有効期限などの未来の日付を管理するものは、未来の日付を扱うことが想定されますが、ホームユースではあまり困らないのでは？という気もします）

世間では紙の資料で「平成32年」などといったものはごろごろしていますので、まだ許容範囲である。文字列から日付型へのデータ変換についても、わざわざ正規化してエラー値判定をしているようなシステムでない限り、「平成32年」を2020年として読み込んで変換する処理になっているものが多い。

日付型としてデータを読み込む際には、単純に元号が「平成」であれば、後続の年数に1988を足せば西暦に変換できるので、弊害を考えればわざわざ正規化してエラーにする必要もない。実際、平成改元の時も同様に昭和年数に1925を足すロジックで「昭和70年」などといったデータをやり過ごしてきたシステムは多い。

かえって、わざわざ元号を「？？」などと変換されてしまった方が、システム的に異常な動作をするシステムが多いことが予想される。特に、新元号が公表されて正しい値に変更された場合には、「平成32年」などというデータよりも、元号が「？？」になっているデータの方が間違いなく異常値として問題となる。実際に異常な動作をするようになってから慌てても始まらないので、警告したわけです。

ある意味、Microsoftは余計なことをしようとしているわけである。

文字列から日付型へのデータ変換についても、わざわざ正規化してエラー値判定をしているようなシステムでない限り、「平成32年」を2020年として読み込んで変換する処理になっているものが多い。

その変換の仕組みが Windows や .NET Framework に頼っているのであれば、いずれ「平成32年」を「2020年」と解釈できなくなりますが、その点は理解された上での主張ですか？

今は 2019/05/01 以降の元号が定義されていないので、平成がそこまで続く前提で処理が行われているので、セーフなだけです。
いずれ、元号が正式決定して 2019/05/01 に対する元号が設定された時点で、「平成32年」は不正値としてエラーになります。
それが、正式運用が始まる前に検知できるようになるという、技術的な意義はあるでしょう。

困る方は、アップデートを少し見送るとか、レジストリを削除するといった対応を取れば良いです。
そのために、ブログとはいえ、情報を公開しているのですから。
ただ、広まりきらないということを危惧されて、情報共有観点で警鐘を鳴らされるのは良いと思います。

かえって、わざわざ元号を「？？」などと変換されてしまった方が、システム的に異常な動作をするシステムが多いことが予想される。

Microsoft の狙いとしては、どちらかと言えば、本運用が始まる前に問題を洗い出すということでしょう。
ゆえに、1803 導入は検証して、必要に応じてシステム更改をしてからという想定でしょうね。

そもそも、半年に一度アップデートする体制を発表した時点で、企業は検証環境で検証し、徐々に展開を始めるようなサイクルを回した方が良い と Microsoft は主張しているので、今更だと思いますが…。

日付型としてデータを読み込む際には、単純に元号が「平成」であれば、後続の年数に1988を足せば西暦に変換できるので、弊害を考えればわざわざ正規化してエラーにする必要もない。実際、平成改元の時も同様に昭和年数に1925を足すロジックで「昭和70年」などといったデータをやり過ごしてきたシステムは多い。

そんなシステムであれば、この改元に対応するレジストリの仕組みなんかに依存してないでしょうから、関係ないのでは？

理想的には元号に依存しない日付型で管理する設計でしょう。
法令によって元号で管理しないといけない分野があるなら大変でしょうけど、そういった市場全体で見れば狭い範囲であれば、レジストリ対応で間に合う気はします。

長くなりましたが、問題点に対する私の意見を書き直すと以下の２点です。

問題１．「平成32年」を「2020年」と解釈できるかどうかはアプリケーションの実装による
Windows や .NET Framework の仕組みを利用している場合、今は「平成32年」を「2020年」と変換できていても、「？？」のレジストリが入るか、最終的な元号のレジストリが入った時点で、変換エラーになります。

こちらの課題に対しては、今の時期に仮の元号のレジストリの定義が入らなくても、いずれ問題になるので、発見が早まるという技術的な意義があると、私は考えています。

問題２．仮の元号が「？？」とか「??」といった可読性や文字の特殊性が気にかかる

その点はそうですね。否定はしません。

ただし、レジストリによる改元の仕組みに依存しないシステムでは影響しないと思うので、実際にどれほど困るかはわかりません。
（昭和65年を解釈できる必要があるシステムは自力実装しているはずなので）

-----

問題２だけを元に「Microsoft は余計なことをしようとしている」と主張されることに違和感を持っています。