コラム

Microsoft製品「Windows」、「Office」、「.net Framework」における新元号対応について(Oracle、postgreSQLについても追記)

更新日:

新元号の発表は
2019年4月1日
もう少しとなりました。

対応について、少しまとめておきたいと思います。

Microsoft製品で対応が必要な製品

Microsoftでは新元号に対する方針について下記にまとめています。

Windows

当然ですが、基本ソフトとなるWindowsです。

対応が予定されているWindows

サポートされるWindowsは
Windows 7 SP1以降
Windows Server 2008 SP2以降
となっており、
Windows Embedded
についても、Widnows 7ベース以降となっています。

対応方法

月例セキュリティパッチを適用することで、対応されます。

なお、実際のところは、
レジストリに新元号の記載を追加するだけです。
これを、4月に公開される月例セキュリティパッチを適用することに対応されます。

そのため、事前にテストする方法も公開されており、

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras] レジストリ パスに以下のエントリを追加します。
“2019 05 01″=”新元号_新_TestEra_E”

こちらを追記し、日付の表示を変更すると対応されます。

同様のレジストリを追記できれば、パッチを適用する必要なないわけですが、
逆にパッチはみんな適用してるからこれなら大きな問題は起きないよねという考えなのでしょう。

※2019/4/2追記
新元号が発表となりましたので、変更用バッチファイルを添付しておきます。
マイクロソフトから公開がありませんが、

令和_令_Reiwa_R

となるかと。
こちらを追加するバッチファイルがこちら。
新元号
こちらを管理者で実行していただければ対象のレジストリが追記されるはずです。

Office

Windowsの次に利用が多いであろうoffice統合製品「Microsoft Office」
こちらも、対応する必要があります。

対応が予定されているOffice

マイクロソフトから公開されている情報については、

https://support.microsoft.com/ja-jp/help/4478844/updates-for-may-2019-japanese-era-change-for-office

2019 年 5 月の日本の元号変更に関する Office の更新プログラム

https://support.microsoft.com/ja-jp/help/4478844/updates-for-may-2019-japanese-era-change-for-office

現在対応が予定されているのは、
Microsoft Office 2010以降
であり、ホームページには、2019年1月にリリースされた、「Microsoft Office 2019」について記載はありません。
「Microsoft Office 2019」
については、これから記載が追加されるかと。

対応方法

対応方法は、Windows同様4月の月例のセキュリティパッチを適用することです。
なお、Officeについては、Windowsのレジストリを参照しないことから、Officeのパッチ適用が必須となります。

Officeについては、
購入方法によりことなり、
プリインストール版やDSP版、パッケージ版といったOfficeについては、インターネットから直接ダウンロード
ボリュームライセンスは、Microsoft UpdateによるインターネットかWSUSサーバからのダウンロード
となります。

企業の場合、困るのが
プリインストール版やDSP版、パッケージ版といったOffice
です。

いままで、家電量販店で買ってそのままインターネットに接続せず利用しているパソコンについては、
4月までに1度インターネットに接続し、最新の状態にしておく方が良いでしょう。

ここで、困ったことがひとつ。
Microsoft Office 2013(32Bit版)については、

まだ、Excel 2013用元号対応用パッチが出ていないことです。
※2019/4/9(日本時間:2019/4/10)に修正プログラムが公開され「Excel 2013(32Bit)」でも表示されるようになりました。

さすがに4月にでるかと思いますが、こちらで検証しているときになぜか元号が確認できなくて、悩んでいたら
Microsoftの公式サイトで追記されました。
そういったことははやめにお願いいたします。(切望)

.net Framework

プログラムの実行環境である「.net Framework」についても対応が必要となります。
色んなソフトがこの「.net Framework」の上で動いているので、知らないところで結構動いているはず。

対応が予定されている「.net Framework」

https://support.microsoft.com/ja-jp/help/4477957

.NET Framework 用の日本の新元号対応更新プログラム

https://support.microsoft.com/ja-jp/help/4477957

現在対応が予定されている「.net Framework」は
.net Framework 3.5以降
です。

対応方法

対応方法については、バージョンによって異なります。
また、.net frameworkの対応は大きく3つあることも注意が必要です。

.net Framework 3.5

こちらは、新元号がプログラムの中に記載されているため、
Windowsの情報を参照するように変更するセキュリティパッチを導入することで、
Windowsが対応することにより、対応されます。

また、元号の範囲と元年表記の対応のセキュリティパッチの適用が必要です。

ただし、この変更により動かないプログラムが発生する場合があるとの
情報もあり、事前にテストしておく方がよさそうです。

.net Framework 4.5.2/4.6以降

こちらについては、Windowsの情報を参照する対応がされています。
しかし、元号の範囲や、元年表記については、セキュリティパッチの適用が必要です。

対応が推奨されるテスト シナリオ
リラックス元号範囲チェック
このテスト シナリオでは、新元号への移行が将来の日付に設定されている場合に、LOB アプリケーションが機能することを確認します。

ある元号の日付が次の元号に “あふれる” 可能性がありますが、既定で ArgumentOutOfRangeException または FormatException はスローされません。 Switch.System.Globalization.EnforceJapaneseEraYearRanges を true に設定すると、厳密な元号チェックを復元できます。

元年
このテスト シナリオでは、日本の新元号の 1 年目として “元年” と表記する書式設定操作を確認します。

.NET の既定の書式設定操作では、”元年” の表記が採用されています。 年を表すときに “元年” ではなく常に “1” と表記する以前の動作に戻すには、Switch.System.Globalization.FormatJapaneseFirstYearAsANumber を true に設定します。

このあたりは、早めにチェックしておいた方が良いでしょう。

Oracle

Oracleについても対応が必要ですね。

https://www.ashisuto.co.jp/support/gengo/product/oracle-database.html

Oracle Databaseの新元号への対応について | アシスト

https://www.ashisuto.co.jp/support/gengo/product/oracle-database.html

postgreSQL

対応不要だが、独自に和暦に関する関数を利用している場合は個別で対応が必要と。

https://www.ashisuto.co.jp/support/gengo/product/postgresql.html

PostgreSQLの新元号への対応について | アシスト

https://www.ashisuto.co.jp/support/gengo/product/postgresql.html

Microsoft SQL Server

最後に

結果として、
Microsoft製品は、日頃からMicrosoft Updateの更新をきちんと実施している人には影響は少なそうですが
「.net Framework」関係で、不具合があったり正しく表示されないシステムがありそうです。

システム担当者は、
.net Framework関係について良く調査してく必要がありそうですね。

ではでは。

-コラム
-, ,

Copyright© Windowsレジストリ置き場 , 2019 All Rights Reserved Powered by AFFINGER5.