元号対応に関するまとめ


元号対応への対策


経済産業省情報


言語、環境


Microsoft


追記


Microsoft製品で参照するレジストリ


Using the Registry to Test the New Japanese Era on Windows


  • 手動追加は、あくまで検証用であることに注意。2019年4月5日説明会資料(2019年4月12日掲載)の33P、60P


    • 検証の際は更新プログラムの適用後、手動で新元号の値を追加して確認


      • 運用環境では、Windows OS の更新プログラムが自動的に値を作成するため手動での作業は不要






元号定義(Windows全体)

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras



Handling a new era in the Japanese calendar in .NET

以下のレジストリは、.NET 4.5.2以前。.NET 4.6以降、.NET Coreはアプリケーション毎の設定ファイルを参照する。

WOW64(64ビット Windows で x86 ターゲット)の場合は、場所が変わるので注意

HKEY_LOCALMACHINE\SOFTWARE


HKEY_LOCAL_MACHINE\Software\Wow6432Node


リラックス元号範囲チェック

Key: HKEY_LOCALMACHINE\SOFTWARE\Microsoft\.NETFramework\AppContext

Name: Switch.System.Globalization.EnforceJapaneseEraYearRanges


フォーマット

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AppContext

Name: Switch.System.Globalization.FormatJapaneseFirstYearAsANumber


パース

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AppContext

Name: Switch.System.Globalization.EnforceLegacyJapaneseDateParsing


Gannen vs Ichinen


元年と1年表記(Win32、VBA、VB6)

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese

Name: InitialEraYear
Value: "1年" (既定値。ただし、2019年5月リリース予定のWindows 10 19H1では元年が既定値予定)


VB6



  • サポートされるOSでは、VB6ランタイムも新元号対応が行われる(レジストリを参照)。



    • 2019/2/22追記修正。経産省資料にて公開対応するOS)。対応OSについて、2019年4月のマンスリーロールアップで対応済み。




独自実装する場合

前提として、公式対応されたため、現在Format関数を使用しているなら基本的には独自実装しないほうが望ましい。OfficeのVBAも同時対応されることからも、OSの累積更新プログラムは適用する必要がある

期間的な制約などで独自実装する場合は次のように行う。


  • 日付から文字列への変換(Format)は、標準モジュールに、Public Format ~ As Stringで宣言することで、オーバーライドできる。


    • As Stringで宣言しないと、Format$が対象とならない(コンパイルできない)。

    • <標準モジュール名>.Format、VBA.Formatとすれば、それぞれの関数を呼び出せる。

    • <標準モジュール名>.Format内のロジックでは、渡されたExpressionが日付型でない(Not IsDate)場合はVBA.Formatを呼び出せば処理が簡単となる。



  • 文字列から日付への変換(CDate, DateValue)は影響範囲が大きいため、オーバーライド以外、または文字列からの変換とならないようなロジックの見直しが妥当と考えられる。


GrapeCity(ActiveX)


対応製品


.NET



  • Microsoftで公式に対応


  • .NET 3.5系、4系ともに、レジストリで対応できる。



  • Microsoft.VisualBasic.Compatibility.VB6.Formatは、OSの対応が必要



  • 既定値は、元年表記((4/14修正)書式指定文字列によるWindows 10 1809用の最新の.NET Framework更新、および他OSでも3/20の更新で、常に元年表記となる修正が加えられた)、リラックス元号範囲チェック(元号範囲移行の平成31年5月などを許容する)有効、となる。

    Handling a new era in the Japanese calendar in .NET


    • .NET 4.6以降なら、.configを設定して、アプリ単位で挙動を設定できる。

    • .NET 4.5.2以前は、レジストリで対応可能だが、「他の.NETアプリにも影響する」ことを検討する。




独自実装する場合


GrapeCity(.NET)


対応製品


  • CalendarGrid for Windows Forms 1.0J/2.0J

  • El Tabelle for .NET 3.0J

  • El Tabelle MultiRow 4.0J

  • El Tabelle Sheet 4.0J

  • El Tabelle Sheet for Windows Forms 4.1J

  • InputMan for .NET 3.0J

  • InputMan for .NET Windows Forms 4.0J

  • InputMan for Windows Forms 5.0J/6.0J/7.0J/8.0J/10.0J

  • InputMan for .NET Web Forms 2.0J

  • InputMan for ASP.NET 3.0J/7.0J/8.0J/10.0J


    • InputMan for Windows FormsおよびInputMan for ASP.NETの自由書式入力機能を使用している場合はGrapeCityの記事を参照



  • InputMan for WPF 1.0J/2.0J

  • InputMan for Silverlight 1.0J

  • MultiRow for Windows Forms 5.0J/6.0J/7.0J/8.0J/10.0J

  • MultiRow for ASP.NET 1.0J

  • PlusPak for Windows Forms 5.0J/6.0J/7.0J/8.0J/10.0J

  • SPREAD for Windows Forms 7.0J/8.0J/10.0J/11.0JのGcDateTime型セル


    • 日付時刻型セルの動作については、GrapeCityの記事を参照



  • SPREAD for WPF 1.0J/2.0J

  • SPREAD for Windows Forms 5.0Jの日付時刻型セル


アドバンスソフトウェア


  • 弊社製品の新元号対応について

  • VB-Reportでは、製品独自機能による帳票出力に新元号を反映させる場合、新元号対応アップデートが必要となる。また、Excelを開いた場合、およびExcelモードを使用するならOS・Office依存となる。


Office

Office 2010以降が対象。

Office製品については、製品のアップデートとOSのアップデートが必要。Excelのセルの書式設定は製品のアップデート、VBA.FormatなどはOSのアップデート。

以下の情報もありますので要確認

「元年」表記に変わる日付書式が今になって拡大!(フレームワーク別の対策が必要)――マイクロソフト様、重大な変更をしれっとリリースしないで | Qiita


ただし、Windows 10 の次期大型アップデート「19H1」の Insider Preview 版では、Format 関数の依存する元年/1年のレジストリ設定 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese] InitialEraYear が "元年" になっているという情報もあり、予断を許しません。


https://support.microsoft.com/ja-jp/help/4469068/summary-of-new-japanese-era-updates-kb4469068の「日本の新元号がサポートされる機能」

VB6、およびOffice VBAの元号対応の状況について | Qiita


Red Hat Enterprise Linux

RHELの新元号「令和」対策お済みですか | 赤帽エンジニアブログ

※リンクされている https://access.redhat.com/solutions/2749651 はアカウントが必要です


Java

別記事に詳細にまとめていただいていますので、ご一読をお勧めします。

Javaバージョン別の改元(新元号)対応まとめ | Qiita


Delphi

別記事に詳細にまとめていただいていますので、ご一読をお勧めします。

Delphi での新元号対応 | Qiita


Oracle

Oracle データベースの日本の新元号「令和」への変更方法について | Oracle Support Japan


文字コード


合字について


その他


明治元年開始日の判定

明治元年の開始日は諸説*1*2あり、言語により実装が異なる。グレゴリオ暦に変わったことによる空白の期間なども踏まえると、アプリケーションとしては、基本的には明治6年1月1日以降をサポートする方針が望ましい。

開発言語
明治元年開始日

VB6
1868/10/23

.NET
1868/9/8 ※明治5年まではグレゴリオ暦が反映されていない

.NET(レジストリ参照時 2019年2月パッチ時点)
1868/1/1

Java
明治6年1月1日より前はサポートしてない

GrapeCity(設定ファイル初期値)
1868/9/8



経産省通達


1.情報システム改修等の対応

(1)元号をデータとして保有している場合、元号データの変更や追加または西暦データへの統一化

(2)書面やシステム上に元号や「元年」を印字・表示している場合、印字・表示内容の変更

(3)西暦と和暦との変換処理を行っている場合、変換ロジックの変更または変換テーブルへの登録

(4)他の事業者や関係機関のシステムと情報連携している場合、当事者間での対応策の必要性確認

(5)その他、必要な対応

2.事務・運用面の対応

(1)元号の記載が含まれる証書・帳票等の記載の変更

(2)旧元号が記載された状態で利用が想定される契約書等の証書や帳票等の取扱の明確化

(3)運転免許証等の官公署発行の証明書等に旧元号が残る場合でも、有効な証明書等として受け付ける措置

(4)顧客に影響が生じうる事項への対応策等に関する顧客への十分な周知

(5)その他、必要な対応

出典:「改元に伴う情報システム改修等への対応について」(経済産業省)




各フェーズ注意


調査・改修


  • OS・ツール、それぞれについて、元号への対応、適用方法について調査する(調査内容 参考)。特に適用方法が自動で行えるかどうかで、設定工数に増減が生じる。

  • 明治元年の開始日が、各OS・ツールで異なる方針となっている場合がある。(多くのシステムには関連がないと想定できるが)

  • 元号が印字済みの帳票がある場合は、印刷会社も交えた調整が必要。

  • 望ましくはないが、和暦年2桁(yy)、和暦元号数値 & 和暦年2桁(gyy)で年を保存、受け渡ししているシステムも考えられるので、考慮が必要。

  • 年までの表記、年月までの表記を行っている場合は、元号判定に使用している情報の確認が必要。(例えば、2019/05に出す帳票で、年表記の場合に、2019/01/01と2019/05/01のどちらを渡しているのか)

  • OCR等も含め、データを和暦でやり取りしている場合は、範囲外の元号(平成31年5月など)も許容することを検討したほうが良い。その場合も送信は厳密に行う。


    • 送信は厳格に、受信は寛容に




運用


  • 他システム(機器)とのファイル交換がある場合には、双方がいつ新元号対応の形式を送り始めるのか、というタイミング、スケジュールの調整が重要となる。場合によっては、特定ファイルのみ、平成での出力、ということも想定される。

  • .NET の標準機能を使用し、CS型のシステムの場合は、他システムへの影響(他システムが元号対応へどのように想定しているか)について調査・調整が必要。

  • 一斉の対応とならない場合は、各種機能の対応スケジュールの確認が必要。


検証


  • 等幅でないフォントで年号を出力する場合は、新しい年号文字で、表示位置がずれていないか、予定外の改行が行われていないかの確認が必要。紙での運用が想定されるなら、想定される環境で出力しておきたいところ。

  • 元号考慮済みのシステムの場合も、元号処理を行っている場所について、最低限一機能は動作確認する。

  • 日付の指定、特に期間指定を行っている箇所については、計算ロジックについて一通り検証しておきたい。(参考 テストケース

  • .NET の元号対応 Windows Update の配布後は、通常の Windows Update に対する動作確認に加え、レジストリを事前登録している場合は、影響を受けていないかを一通り検証する(基本的にはレジストリの手動追加は、検証環境のみ、とされている)。2019年1月にOffice2010で発生したように、対応するKBが別の障害を起こすこともあるので、早急、かつ慎重な検証が必要となる。

  • 並び順について確認が必要。(表示値で並び替えている場合)

  • 内部に和暦でデータを保持している場合は、未来の日付が想定される場合について特に注意が必要。



改修またはテスト必要箇所調査のヒント


VB6


  • 日付型から文字列に変換しているか。(Format


    • "ggg","gg","g","ee","e"(大文字小文字区別しない)



  • 和暦文字列から日付に変換しているか。(CDate, DateValue


    • VB6はリラックス元号変換。基本的には西暦文字列が使えないかを検討する。



  • 日付の計算で和暦文字列から変換しているか。(DateAdd


    • VB6では、Option Strict On がないため、自動的に日付型へ変換される。




.NET


  • .NETの機能を使用する場合



    • JapaneseCalenderを使用しているか


      • "ggg","gg"(大文字小文字区別する)



    • Frameworkのバージョンは何か。(4.5以前は、設定(リラックス元号変換、和暦表記)がホスト共通となる)


    • VB6.Formatを使用していないか



      • Microsoft.Visualbasic.Compatibility.VB6を参照して、VB6.Formatを使用している場合、VB6.Formatは、VBA(VB6)が対応したタイミングでの対応となる





  • .NETの機能を使用しない場合



    • JapaneseCalenderを使用していないか。




サードパーティ


  • コンポーネント固有の機能(例えばActiveReportsなら、フィールドのプロパティOutputFormat)を使用して和暦文字列変換を行っていないか


Office


  • 出力物として使用している場合、元号変換にExcel、Accessの書式を使用しているか。


共通


  • 規約外の和暦計算(コード、SQL)



    • 1988を使用している(2019 - 1988 = 31)


    • 2000を使用している(2019 - 2000 + 12 = 31)


    • 1925を使用している(1979 - 1925 = 54)


    • 19261224を使用している(昭和開始日)


    • 19890107を使用している(平成開始日)



  • 埋め込み



    • 平成を埋め込んでいる


    • Hを埋め込んでいる


    • 4を埋め込んでいる



  • 年度判定


    • 年度を表示している場合、元号取得に使用している年月は正しいか(4~3の年度なら、4月だが、1月の年度を使用している、など)



  • 表示値で並び替えていないか。(仕様または実装不具合に該当)


DB


  • 下記に該当する場合は、入力可能な日付の範囲により、適切なタイミングでのデータ変換の必要性を検討する。


    • 和暦文字列(例:平成31年5月1日)を保存していないか

    • 和暦数値(例:4310501など)を保存していないか

    • 和暦年のみを保存していないか




Oracle



  • Japanese Imperialを使用していないか(参考


帳票


  • 元号文字列の埋め込みがないか。("平成","平","H")


    • ソース

    • 帳票フォーマット




ファイル


  • 和暦年号のみの入力がないか。

  • 入出力インタフェースで、和暦文字列、和暦数値が使用されていないか。


    • 外部システム連携ならタイミングを検討




配布方法


  • 元号追加に関わる設定の設定方法


    • 設定範囲(ホスト全体、アプリ)

    • 適用箇所(サーバー、クライアント)

    • 配布方法(必要な権限、オンライン・オフライン)

    • 再起動の必要性





リソース


Microsoft


最新情報


展開と運用、テストケース


Microsoft.VisualBasic.Compatibility.VB6.Formatや、VBA.Formatから呼び出されていると思われるAPI


新元号に関するセミナー


ビジネス+IT


PC Watch


キーマンズネット


Ashisto(Oracle)


GrapeCity