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

Microsoftは、新元号対応の事前更新としてWindows 10 ver.1803で.Net Framework4系の設定が変更されることが公表した。

記事:

https://blogs.technet.microsoft.com/jperablog/2018/04/20/rs4-registry/

https://blogs.msdn.microsoft.com/shawnste/2018/04/12/the-japanese-calendars-y2k-moment/

この変更により、元号が「??」で表示され、"2020/10/10" は和暦で "??2年10月10日" と表示されるようになります。
うっかり文字としてデータベースなどに登録されると惨事を招きかねません。
いくら日本政府の新元号の公開が遅いからといって、中途半端な修正は迷惑です。

Windows Updateが行われた場合には、変更が行われているかどうか気を付けていただきたい。

この動作を無効にする場合には、この修正で追加されるレジストリの項目を削除する必要があります。

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras]
"2019 05 01"="??_?_??????_?"

逆に言えば、これで元号表示が変わらないような場合には、ユーザマクロやアプリケーションで独自に元号処理を実装している可能性が高く、ユーザマクロやアプリケーションを変更する必要がある可能性が高いということになります

参考:Windowsの改元対応問題

このディスカッションは役に立ちましたか?

役に立ちませんでした。

素晴らしい!フィードバックをありがとうございました。

このディスカッションにどの程度満足していますか?

フィードバックをお送りいただきありがとうございます。今後のサイト改善に役立てて参ります。

このディスカッションにどの程度満足していますか?

フィードバックをお送りいただきありがとうございます。

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

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

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

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

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

この返信が役に立ちましたか?

役に立ちませんでした。

素晴らしい!フィードバックをありがとうございました。

この返信の満足度をお教えください。

フィードバックをお送りいただきありがとうございます。今後のサイト改善に役立てて参ります。

この返信の満足度をお教えください。

フィードバックをお送りいただきありがとうございます。

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

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

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

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

10 ユーザーがこの返信を役に立ったと思いました

·

この返信が役に立ちましたか?

役に立ちませんでした。

素晴らしい!フィードバックをありがとうございました。

この返信の満足度をお教えください。

フィードバックをお送りいただきありがとうございます。今後のサイト改善に役立てて参ります。

この返信の満足度をお教えください。

フィードバックをお送りいただきありがとうございます。

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

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

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

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

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

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

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

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

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

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

この返信が役に立ちましたか?

役に立ちませんでした。

素晴らしい!フィードバックをありがとうございました。

この返信の満足度をお教えください。

フィードバックをお送りいただきありがとうございます。今後のサイト改善に役立てて参ります。

この返信の満足度をお教えください。

フィードバックをお送りいただきありがとうございます。

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

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

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

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

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

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

-----

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

30 ユーザーがこの返信を役に立ったと思いました

·

この返信が役に立ちましたか?

役に立ちませんでした。

素晴らしい!フィードバックをありがとうございました。

この返信の満足度をお教えください。

フィードバックをお送りいただきありがとうございます。今後のサイト改善に役立てて参ります。

この返信の満足度をお教えください。

フィードバックをお送りいただきありがとうございます。

 
 

ディスカッション情報


最終更新日 2020年1月16日 表示 14,982 適用先: