[16] 元号コードとは、
計算機システムの処理や情報交換などに用いる日時形式において、
元号に符号を割り振って識別するものです。
元号の名前自体がある種の符号とも言えますが、
元号コードはそれを更に扱いやすい値に置き換えたものです。
[38] いくつかの流儀があります。
明MU+337E (㍾)大TU+337D (㍽)昭SU+337C (㍼)平HU+337B (㍻)[20] 多くの方式は、日常の業務で必要な範囲の元号のみ定義しています。 最も多いものは明治以後のみ対応しているもので、 昭和以後のみ対応のものもあります。
[8008]
この JSON データファイルでは、古今東西の (日本以外も含む)
元号に固有の正の整数の数値識別子 id (紀年法識別子)
が割り当てられています。
明治以後は 1 から順に割り当てられ (#1)、 19 まで予約されています。
20 には西暦が、 21 以降には色々な元号と紀年法が割り当てられています。
[8001] 明治を 1 とし、以後日本の元号を順に割り振っていくものが数値符号として主流 (事実上の標準) のようです。 平成は 4 となります。
[34] 令和より後も、改元があるたびに自然な順序で追加されていくことが期待されます。
[112] COBOL で書かれたプログラムなどでは、 「3600214」 でを表すように、 日時形式の一部としてよく使われています。
[109] .NET Framework でも採用されています >>108 (#1)。
[25] その他を 9 で表す場合もあります >>13, >>14 (#18)。
[8017] 西暦を 0 で表す場合もあります >>28 (#17)。
[8025] 西暦を 9 で表す場合もあります >>142, >>143, >>149 (#25)。
[163] 不明を 0、西暦を 9 で表す場合もあります >>164 (#26)。
[91]
Java の
JapaneseImperialCalendar
は「明治以前」
を 0
で表しています (#19)。
>>138
JapaneseImperialCalendar
[8016]
戸籍情報システム標準仕様書は、
明治以降を 1
から順に割り当てると共に、
元治を Y、
慶応を Z
としています。
慶応以前はアルファベットを逆順、
明治以降は数字を昇順と説明があります。 >>53
(#16)
[61]
理論上 X 以前も A まで遡れますが、
どこまで利用されているかは不明です。
仕様書には Y からしか示されていませんが、
採番方法が明記されており、
よく使われるものを例示したに限らないとも思われます。
平成後期の報道によると、
文化年間生まれの人が死亡とされないまま現行戸籍に残されていました
>>85。
平成30年時点で戸籍電算化はほぼすべての地方自治体で完了しており、
X 以前の日付の記述が必要となった可能性はあります。
なお、複数の家系調査業者の Web サイトによると、
(電算化はともかく) 戸籍で遡れるのは文化頃までのようです。
[35] 元号コードが十進数1桁となっている実装では、 10 以降 (9 に特別な意味を持たせる場合、 9 以降) の改元があっても対応できません。 十六進数1桁となっている実装では、 16 以降の改元に対応できません。 それらがいったい何年後に訪れるかはまったく予測できませんが、それまでに改修が必要となります。
[39] その頃には明治も遥か昔の元号となっているでしょうから、 1 から再利用することも可能かもしれませんが、混乱は避けられなそうです。 古い時代の記録が残っているとデータが滅茶苦茶になりますし、 日時の整列操作を元号コードの数値としての大小で行っていると破綻します。
(C)元号コード
元号 元号コード
昭和 3
平成 4
元号コード 元号名
---------------------
1 明治
2 大正
3 昭和
4 平成
@ 生年月日欄 (39~45カラム) 組合員の生年月日を元号コード (大正二 2、 昭和 二 3、 平成エ 4) を含めて記入します。 また、 生年月 日は右詰めで記入し丶 空きマスには0を記入します。
元号を扱うシステムのほとんどで、元号コードを1:明治,2:大正,3:昭和,4:平成と定めているので、新たに5:新元号を作ることとなります。
N1 : 元号コード 1;明治 2;大正 3;昭和 4;平成
昭和30年1月2日
生年月日
西暦 明治 大正 昭和 平成 年 月 日
0 1 2 '3 4 0 0 3 0 0 1 0 2
西暦1955年10月23日
生年月日
西暦 明治 大正 昭和 平成 年 月 日
0 1 2 3 4 1 9 5 5 1 0 2 3
元号コードは以下のようになります。
元号 元号コード
明治 1
大正 2
昭和 3
平成 4
和暦の元号と年、月日で構成される日付文字列です。
元号コードは以下のようになります。
元号 元号コード
明治 1
大正 2
昭和 3
平成 4
平成23年7月25日は 4230725 と表記されます。
[160] e-Tax仕様書一覧 | 【e-Tax】国税電子申告・納税システム(イータックス), 国税庁, https://www.e-tax.nta.go.jp/shiyo/shiyo3.htm#Link1
[161]
>>160 元号コードは 1 から 5 とされています (配布CABファイル内の
02_レコードの内容及び留意事項.pdf)。
XML ファイル内では元号コード, 元号年, 月, 日が別の要素の内容として記述されます。
[137] 改元“平成”初日…1989年1月8日の街の様子 印鑑店は“平成スタンプ”製作 役所では元号訂正に追われる タイムマシーン“ユウガク”【長崎】 | TBS NEWS DIG (1ページ), 2024年1月8日(月) 11:00, https://newsdig.tbs.co.jp/articles/-/927005?display=1
[122] >>137 長崎市役所の行政事務用端末の画面と思われる写真があります。
「
[8005] 昭和を 1 とし、以後順に整数を割り当てていくものです (#5)。
[60] 1桁の数字とするもの >>11 や 0埋めした2桁の数字とするもの >>26, >>27 が知られています。
[8020]
[101]
java.time.chrono
は昭和を 1
としていますが、
大正は 0、
明治は -1
としています
(#20)。
>>93
ア:承認した年(数字3桁)
昭和・・・1
平成・・・2
これに元号の年数(2桁)を組み合わせる。
変更点 変更前 変更後 年月日の入力方法 西暦の年を示す4桁の数字,月を示す2桁の数字及び日を示す2桁の数字をこの順に並べて入力する(例:20080901)。 元号を使用し,元号を示す元号コード,年を示す2桁の数字,月を示す2桁の数字及び日を示す2桁の数字をそれぞれの項目ごとに入力する。
表7-3.元号コード一覧
コード名称 桁数 コード 内 容 元号コード 2 01 昭和 元号コード 2 02 平成
[8006] 昭和を 1 とし、 大正を 2、 明治を 3 と遡っていくものです。昭和時代に設計されたものなのでしょう。 設計者は次の改元のことを何も考えていなかったのでしょうか。 平成には 4 が割り当てられており、 以後の改元でも順に大きな整数を割り当てていくものと思われます。
受給者の生年月日の元号、年、月及び日を記録する。この場合、元 号については、昭和は「1」、大正は「2」、明治は「3」、平成 は「4」を記録し、また「年」、「月」及び「日」については、そ れぞれ別項目で2桁を使用する。
元号については、昭和は「1」、大正は「2」、 明治は「3」、平成は「4」、その他は「9」を記録 し、また、「年」、「月」及び「日」は、それぞ れ別項目で2桁を使用すること。 (例)「平成17年8月19日 → 4.17.08.19」
受給者の生年月日の元号、年、月及び日を記録する。この場合、元 号については、昭和は「1」、大正は「2」、明治は「3」、平成は「4」、 その他は「9」を記録し、また「年」、「月」及び「日」については、 それぞれ 2 けたを使用し、1 けたの場合は後づめ(前ゼロ)で記録す る。
第5版(平成30年4月1日)
1
元号
※3 平成の次の元号は、「2」とする。
元号コードについて、平成の次の元号となった場合 の記載方法を追記
[8004] 明治以後の元号に 1 から順に奇数を割り当てる数値コードが使われることがあります。
[48] 1桁の十進整数として扱う場合、平成31年新元号の 9 で使い切ってしまいます。該当するシステムは2桁化改修 >>44 が予定されていたりするようです。
なお、「元号」欄には、明治は「1」、大正は「3」、昭和は「5」、平成は「7」のいずれかの該当するコード番号を記入して下さい。
先般、皇室典範特例法が成立・公 布され、早ければ平成31年1月に 改元がなされる見込みとなったこと から、①次期更改と同タイミングで 新元号に係る元号コードの利用を可 能とする改修及び②次期更改後に元 号コードの枯渇を防止するため元号 コードを二桁化するための改修(以 下「新元号対応」という。)を行うも のである。
・次元号対応:平成 31年1月上旬 (※2) ・二桁化対応:平成 32年2月下旬
1 新元号をコード「9」(労災・基準サブシステム)、「5」(レセプトサブシス
テム)」とする暫定対応を行う。
①入力画面で新元号の入力を可能とし、出力画面で新元号を表示可能
とする。
②入力帳票(OCR帳票)で新元号を入力可とする。
③入力帳票(OCR帳票)のうち元号欄を持たない帳票は、帳票入力を原
則不可とする。(一部を除く)
④国民向け帳票出力、及び内部出力帳票に新元号を出力する。
⑤元号欄なし出力帳票へ元号欄を追加する。
⑥外部連携ファイルのIFを改定し、新元号の入出力可とする。
⑦入力帳票(OCR帳票)の入力値凡例を追加する。
⑧電子申請様式で新元号を入力可とする。
2 年表示に係る「元年」、「1年」の画面・帳票表示については、前提条
件⑦に示す内容を踏襲することを想定しているが、、労災保険業務課と
協議の上で統一を図ること。
3 年表示に係る「元年」、「1年」の画面入力については、前提条件⑦に
示す内容を踏襲することを想定しているが、労災保険業務課と協議の
上で統一を図ること。
4 年表示に係る「元年」、「1年」のOCR帳票への記載(OCR入力)につ
いては、前提条件⑦に示す内容を踏襲することを想定しているが、労災
保険業務課と協議の上で統一を図ること。
労働基準行政システム全部(基準・労災サブシステム(共通番号連携管
理サブシステム含む)、レセプトサブシステム)を対象とする。
①新元号は漢字2文字
和暦で入出力する画面、帳票、外部連携ファイルは、元号部分を全角2桁
の領域で定義しており、次元号が3文字以上となる場合は領域の拡張等
別途必要な対策を行うこと
②新元号コード
基準・労災システムで扱っている元号コードは1:明治、3:大正、5:昭和、
7:平成であり、新元号コードは「9」とする。
レセプトシステムで扱っている元号コードは1:明治、2:大正、3:昭和、4:
平成であり、新元号コードは「5」とする。
③改元の時期
改元は2019年1月1日(平成31年1月1日)に行われるものとして、西暦から
和暦への変換は、2018年12月⇒平成30年12月、2019年1月⇒新元号の1
年(元年)1月として扱うものとする。
④未来日を出力する画面・帳票の扱いについて
支払予定日や有効期間等、システム処理日から見て未来日を出力する画
面・帳票が存在する。
しかし、改元自体は2019年1月1日であるため、改元前の2018年(平成30
年)の機械処理で2019年の日付を出力する場合は従来どおりの元号「平
成31年」として出力することとし、改元後の2019年の機械処理で2019年の
日付を出力する場合は「新元号の1年(元年)」として出力するものとする。
⑤ソフトウェアの元号対応について
ソフトウェアの機能を利用して和暦の出力を行っている機能が存在するた
め、以下のソフトウェアが新元号に対応し、本番環境にそのバージョンが
適用されるものとする。
ListCreator(日付編集形式の元号)
Microsoft Office(Excel、Wordの日付形式)
Microsoft .NET Framework(DateTimeクラス)
⑥リリース時期については、改元日の確定時に決定するものとする。
⑦現行の基準システムにおける表示及び入力について
・画面・帳票表示:「元年」
・画面入力:いずれも入力可
・OCR帳票への記載(OCR入力):「1年」
①和暦管理している項目を西暦に変換する。(データ移行が必要)
②全画面全帳票の内部処理を見直し、改修を行う。
労働基準行政システム全部(基準・労災サブシステム(共通番号連携管
理サブシステム含む)、レセプトサブシステム)を対象とする。
・システム内で管理する元号コードを2桁化し、その対象を明治、大正、昭
和、平成、H31.1改元予定の新元号の5つとする。
・システム内で管理する元号コードは2桁化するが、帳票、画面のレイアウ
ト変更が発生しないよう、見た目上は1桁表示のままとする。
・元号コードの2桁化対応として、以下を実施する。
- サーバ側の共通処理として元号コード変換処理(1→2桁)を追加する
- 労災、基準、電子申請システムの各影響箇所を改修する。
・現状和暦管理されているDB項目はすべて西暦に変更する。
日本年金機構で使用する新元号の「コード」が「9」となりました。弊社におきまして も同様に新元号の「コード」として「9」を使用することといたします。
日本年金機構へご提出いただくデータ等に使用する新元号を表す1桁の数字(コード)が「9」 となりました。(厚生労働省宛確認しております。)
<日本年金機構における元号を表す「コード」>
明治:「1」 平成:「7」
大正:「3」 新元号:「9」
昭和:「5」
[156] 000686372.pdf, , https://www.soumu.go.jp/main_content/000686372.pdf#page=86
1桁目には生年月日の元号コードを設定す
る 【明=1、大=3、昭=5、平=7】 2~7桁目には元号を除く生年月日(和暦) を設定する
[8015] 森本角蔵の日本年号大観の通し番号です。 日本の元号のうち南朝を採り、 北朝は別系列の番号を振っています。
[121] 白鳳を含み元暦を含まない点が #14 と違います。 日本年号史大事典などに #14 と #15 の差分が示されています。
[8014] 所功らの日本年号史大事典の通し番号です。 日本の元号 (北朝、南朝どちらも含む公年号すべて) に整数を割り振っています。
[104]
現代日本では日本の元号全体の数え方として、
事実上の標準となっています。
[152] [8024] 元号「令和」 ―改元と皇位継承―は大化から平成までに連番を割り振っていました >>153 (#24)。
[155] ドキュメント新元号平成 (毎日新聞政治部, 平成元年) pp.251-257, 歴代天皇・年号事典 (米田雄介編, 平成15年), 元号全247総覧 (山本博文編著, 平成29年) を参考に筆者が作成と書かれており >>153、 番号が4者のいずれによって振られたものかは不明です。
[8010]
#10
CLDR元号コードは
CLDR が対応している日本の元号
[107] CLDR と密接に関係する ICU の Japanese Calendar の実装が使っている番号でもあります >>106。 ここでいう Japanese Calendar は元号年です。
[102] 0起源です。白鳳を含み、北朝の元号のいくつかを含まない (なぜかいくつかは含む) ため、 #14 や #15 と一致しません。
[8002]
明治を M などと元号名をローマ字化して頭文字を取って記号とするものです。
平成は H、令和は R
となります。この方式は機械処理のみならず、人間による略記でもしばしば用いられます。
[51] 明確に符号として定義される場合は大文字を使うことが多いです。 人間が日時形式の一部分として用いる場合には小文字とされることもあります。
[36] 先頭1文字で自動的に決まるので、揺れは見られません。将来的に衝突が生じた場合や、 「ち」 (chi / ti)、「じ」「ぢ」 (ji / zi / di)、「づ」 (du / zu) などから始まる元号の場合に、 揺れが生じる可能性はあります。
[71] 令和改元では R と L の揺れの可能性がありましたが、
に政府に取材した媒体がヘボン式を使うとの見解を得て記事化し、
R に確定しました。
その後内閣官房の Webサイトで英語版の発表文が掲載され、
経済産業省もヘボン式であることを明示する文書を発表しました。
JIS X 0301:2019 も R を採用しました。
[37] おそらく数代前の元号との衝突は避けるように制定時に配慮されるでしょうが
(
[22] この方式は人間が関わる場合の入出力などには適していますが、 将来的な衝突の可能性や整列の便宜などを考えると数値符号の方が便利そうです。
[52] JIS X 0301 の元号による日時表記でも、本方式が採用されています。
[33] 日本政府の消費者庁は本方式による賞味期限表示例を示しています。
[57] 日時を扱うプログラミング言語のライブラリーは、 本方式による出力機能を有していることがあります。
[80] CLDR は、 明治以後を大文字1文字、 それ以前は本来表記そのままのものを元号の短い表記として採用しています >>79。
[129]
私年号の霊波や立教は、 R
と省略されることがあり、
令和と衝突しています。
日時表示での利用は見られますが、
元号コード的な利用は確認されていません。
3 「変更年月日」の欄は、最初の□には元号のコードとして「H」を記入するとともに、□に数字を記入するに当た って、空位の□に「0」を記入すること。 (記入例) H 0 5 年 1 1 月 3 0 [平成5年11月30日の場合]
掲載日:2015年5月1日
元号コード
M 明治 T 大正 S 昭和 H 平成
「生年月 日」、 「認定年月 日J 及び 「合格年月~日」 の欄は、 最初の口には下表より該当す る元号のコードを記入すると ともに、 口に数字を記入するに当たっては、 空位の口に 「。J を記入すること『 ' (記入例) 回一0篇エ 年 0量8 月 2量3旦 M 明 治 S 昭 和 〔平成元年8月23日の場合] T 大 正 H 平 成
元号は下記の略号で記入する。
平成…H
昭和…S
大正…T
明治…M
NHKはその後、元号の選定手続きでは、政府原案として「平成」のほかに、「修文(しゅうぶん)」と「正化(せいか)」という2つの案もあったと伝えています。
さらに、コンピューターなどで、明治は「M」、大正は「T」、昭和は「S」とアルファベットの頭文字で処理もされているため、全閣僚会議では、「『修文』や『正化』では、頭文字が、昭和と同じ『S』となり、不都合なのではないか」という意見が出されたと紹介しています。
[140] >>136 明治は英字1字の略号、それ以前はフルの元号名で表した例。
[159] 001380373.pdf, , https://www.mlit.go.jp/common/001380373.pdf#page=7
[8007] 「平成」を「平」とするような、 先頭1文字による略記が用いられることがあります。
[54] 文書番号に組み込まれた年部分で使われることもあります。
[55] JIS X 0301 の元号による日時表現でも使われています。
[58] 日時を扱うプログラミング言語のライブラリーは、 本方式による出力機能を有していることがあります。
[86] 戸籍システムの仕様書では (システムで扱うものでなく説明文中でですが) 元治を「元」、 慶応を「慶」としています。 >>53
[124] 日本の国立国会図書館の書誌情報の日付欄の表記はいろいろなものが混在していますが、 「明44,大4」 のように略記したものもみられます。
[82] 元号からの類推で西暦 (AD) の略号を「A」 とするシステムもあるようです。 しかし人間にとってこの略記は一般的ではなく、 「A2019」のように記載しても理解してもらえる可能性は低いとみられます。
[113] 元号コード以外の純粋な省略の用法は元号略号を参照。
[8003]
[8011]
[8012]
[8013]
[8021]
[8022]
[8023]
かつて日本で使われていたシフトJISや現在世界的に使われている
Unicode
のような文字コード規格では、元号名を1文字扱いとした元号合字が、
明治とそれ以降の近現代の日本の元号について符号化されています。
[87] 厳密にいえば元号を識別する元号コードではなく、 元号名を1つの文字としたとき、それを識別する文字コードですが、 広い意味で元号を表す符号ではあります。
[137]
越南の元号についての論文
ベトナムの漢字年号について⸺李王朝を中心に⸺
は、
越南の元号について、王朝ごとに連番を振っています。
ただしこの論文のの日本語版との越南語版で番号が変わっています。
[30] 「H21第13号」のように、元号年の略号と年内の連番を組み合わせることがよくあります。
[74] 新しいシステムでは、もっとも広く採用されている #1 方式を踏襲するべきです。 平成以後のみ、 令和以後のみのごとく直近の元号しか必要としない場合であっても、 無意味なバリエーションによる混乱を抑えるため #1 に共通化していくのが好ましいです。
[75] 将来の改元による桁溢れを防ぐため、 最低でも4ビット (0 - 15)、 できれば8ビット (0 - 255) の保存領域を確保するべきです。 元号コードの数値を文字列や二進化十進数として扱う場合は、 最低でも2桁 (00 - 99) を確保するべきです。
[135]
情報交換用の日時形式では、固定長を避け、
- や , のような適切な区切子を配置し、
桁数が増えても問題が起きないようにするべきです。
[120] 日本の元号全体を扱う必要がある場合は、 日本の元号研究の基礎となる文献といえる 日本年号史大事典の #14 に従うべきです。 8ビットにぎりぎり収まりますが、将来性が心もとなく、 最低でも16ビットは確保するべきです。
[76] 現代日本の元号と西暦に限定されない様々な元号や紀年法に対応する場合は、 #1 を更に拡張した #8 を使うべきです。 この場合は更に大きな保存領域が必要となります。
[77] 人間向けでは、英字の #2 を使うこともできます。 将来英字の枯渇で衝突するおそれがあるので、 利用者インターフェイスの入出力でのみ使うべきで、 内部形式や情報交換用形式には数値を使うべきです。
[132] 日時の情報交換を目的とする場合、 元号コードと年数の組み合わせは使うべきではありません。 「平成32年1月2日」のような延長年号の取り扱いに疑義が生じたり、 新元号への移行期間の相互運用性に支障が生じる危険性があったりするためです。
[133] 日時の情報交換では Unix time のような整数時刻系や、 HTMLの日時形式のような改元の影響を受けない日時形式を採用するべきです。 元号年とそうした情報交換形式との変換は、入出力時に行うべきです。
[123] 原則的に数値の元号コードを人間の利用者に入力させることは避けるべきです。
select のように元号を選択させる方法を採用するべきです。
[125] 補助的な入力手段として元号コードでも入力できるのは問題なく、
場合によっては望ましいともいえます。熟練の作業者は select
で選択するより元号コードの方が効率的に入力できます。
[147] 検索など、元号コードを活用すると効率的に利用できる場面もあります。 ユースケースに合わせて柔軟に設計することが望まれます。
[148] 原則的に数値の元号コードを人間の利用者に単体で提示することは避けるべきです。 元号名に変換して表示するべきです。
[151] 元号名と元号コードの併記は適宜活用されるべきです。 例えば前近代の元号が出現する場面では、元号コードが大いに活用されると想定できます。
[158] 年を入出力させる場面では、 用途に応じて元号コード、元号年、西暦年、干支年、年齢などを柔軟に組み合わせて便利に使えるようにするべきです。 保存や通信に使うデータ構造と人間の入出力の構造が同じである必要はありません。 例えば西暦年で入力させて元号コードと元号年に変換したり、 十二支年で元号コードと元号年の選択肢を絞り込んだりすると便利なことがあります。
[97] 元号の名前、読み、
本項に掲げた各種元号コードの値、
改元日その他の情報をまとめた JSON データファイルです。
[98] 各コードの比較 (古い時代も含む):
[114]
元号名の先頭文字の略号は、
手書きの時代から便宜上用いられていたと思われます。
[117] やがて提出用書類の様式の日付記入欄でも字数節約のため、 あるいは文書番号の類の構成要素としても用いられるようになったのでしょう。
[115] 英字略号は、それに加えてローマ字表記が日本人に普及して初めて一般化し得たものといえます。 昭和時代後半頃でしょうか。 さらに昭和時代末期頃には電算処理にも使われるようになりました。
[116] 数値符号は、 昭和時代末期頃、電算処理の都合上使われはじめたと推測されます。 マークシートや OCR 処理される用紙のような形で一般人が記入させられることもあったでしょう。
[111] 都道府県コードや性別コードのように情報処理の基本要素の多くは JIS などで標準化されているのですが、 (JIS X 0301 の英字符号を除くと) 元号コードはなぜかそうしたものの対象になってきませんでした。 そのためなのか #1 が事実上の標準になっているとはいえ、 それ以外のいろいろな方式も無視できない程度に使われていて、 統一されていません。
[119] 学術的な場面で元号に数値符号を割り振ることは意外と少ないようです。 学術論文や専門書で元号に言及する場合、 自明のものとして特に説明もなく用いるか、 日本の元号以外なら国 (王朝) を補足するか、 あとは西暦年を付記する程度です。 そもそも全時代の元号を扱う研究がそれほど多くないということもあります。
[110] 元号コードを使った日時の記述は、 官公庁を中心に情報システムで広く使われているとみられます。 ところが単独の符号体系を説明するものがあるのは当然として、 いろいろな符号体系を総合的に扱ったものは、 平成時代末期の本ウィキページにまとめられるまで、 なぜかありませんでした。 (もしかすると古い時代の情報技術者向け書籍・雑誌を探せばあったのかもしれませんが。)
和暦が新しい元号(「平成」の次の年号)へ変更された場合の対応方法は、製品によって異なります。
1. 外部ファイル(構成ファイル)による年号の設定
以下の.NET製品には、アプリケーションの構成ファイル(app.config、web.config、app.xaml)を使用して、コントロールが出力する和暦の年号を独自に定義できる機能が用意されています。年号が変更された場合は、構成ファイルに新しい年号の情報を記載することで、対応が可能です。
2. .NET Frameworkの和暦機能を使用している製品
前述1.以外の.NET製品(ActiveReports for .NETなど)は、独自の和暦機能を持っていません。.NET FrameworkのJapaneseCalendarクラスなどを利用して、和暦を出力します。
項番1
第三者行為災害情報の任意登録機能
②受付番号を局署別・年度別となるように自動採番
(付番例:1301-26-0001、局署-和暦-連番)する。な
お、表示に当たっては、業通別が判別可能なコード
等を付与する。(表示例:1301-26-0001-業)
受付番号の例について、「局署-和暦-連番」となっていますが、和暦ではな
く西暦4桁とする方が望ましいのではないでしょうか。
元号変更に伴い01に突如戻る可能性があることから、受
付番号が一意にならない可能性があります。
一意性を失った場合、検索画面で結果をソートして表示す
る際、意図せず古いものと新しいものが混ざって表示され
るといった弊害が想定されます。
再検討の結果、「局署-元号-和暦-連番」に変更いたし ます。
「元号」は、平成「7」とし、表示例を 1301-7-26-0001 に 変更します。
[56] 日付の年号を略称で表示するには?[C#、VB]:.NET TIPS - @IT () http://www.atmarkit.co.jp/ait/articles/1506/10/news022.html
[139] Re[5]: VBで和暦コード(1~5)から元号を取得する方法, http://bbs.wankuma.com/index.cgi?mode=al2&namber=97149&KLOG=168
前項の年度の表示は、文書番号を付した日の属する年度の元号の最初の一文字及び当該年度を表す数字によるものとする。
「生年月日」及び「変更年月日」の欄は、最初の□には下表より該当する元号のコードを記入するとともに、□に数字を記入するに当たつては、空位の□に「0」を記入すること。
(記入例)
H
0
6
0
4
1
1
M
明治
S
昭和
〔平成6年4月11日の場合〕
T
大正
H
平成
年月日には元号(「明治」は「明」、「大正」は「大」、「昭和」は「昭」とする。)を付して記入する。
年月日には元号(「明治」は「明」、「大正」は「大」、「昭和」は「昭」とする。)を付して記入する。
第七条 文書記号は、次に掲げる文字又は数字を順に表記した一連の表現による。ただし、これにより難い場合は、総務課長に協議のうえ文書管理責任者が定める。
一 ローマ字の大文字により表記した元号の冒頭の文字
二 アラビア数字により表記した元号の年度
三 「仙ガ」及び主務課の一字
文書記号は、次に掲げる文字又は数字を順に表記した一連の表現による。ただし、これにより難い場合は、文書法制課長と協議の上、文書管理責任者が別に定めるところによることができる。
一 ローマ字の大文字により表記した元号の冒頭の文字
二 アラビア数字により表記した元号の年度
三 主務の局又は区役所、部及び課等の各冒頭の文字
文書記号は、次に掲げる文字又は数字を順に表記した一連の表現による。ただし、これにより難い場合は、総務課長と協議の上、文書管理責任者が別に定めるところによることができる。
一 ローマ字の大文字により表記した元号の冒頭の文字
二 アラビア数字により表記した元号の年度
三 「消」並びに主務の部又は署及び課等の各冒頭の文字
年を和暦で指定するには、年の前につぎのいずれかの文字列をつけます。
元号 和暦文字列
明治 明治、明、M、m、メ
大正 大正、大、T、t、タ
昭和 昭和、昭、S、s、シ
平成 平成、平、H、h、ヘ
元号を扱うシステムのほとんどで、元号コードを1:明治,2:大正,3:昭和,4:平成と定めているので、新たに5:新元号を作ることとなります。
⑵ 元 号 で の パ タ ー ン 分 け
元 号 区 分 元 号 区 分の 意 味 留 意 点 0 - - 1 明 治 明 治 1 年 9 月 8 日 ~ 明 治 45 年 7 月 29 日 の 範 囲 内 2 大 正 大 正 1 年 7 月 30 日 ~ 大 正 15 年 12 月 24 日 の 範 囲 内 3 昭 和 昭 和 1 年 12 月 25 日 ~ 昭 和 64 年 1 月 7 日 の 範 囲 内 4 平 成 平 成 1 年 1 月 8 日 以 降
来年5月1日に改元を迎えるにあたりまして、下記の記録条件仕様の「別表_年号区分コ ード」に、コード「5」を追加する予定であることをお知らせします。
[83] エクセルの表で、元号を数字にして入力しているセル(平成20年5月5日だ... - Yahoo!知恵袋 () https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1094612405
[84] エクセルの日付形式で、元号(昭和ならS、平成ならH)を任意の数... - Yahoo!知恵袋 () https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1211367182
[89] CLDR: #11839 (Japanese square era name symbol collation) – CLDR () https://unicode.org/cldr/trac/ticket/11839
[90] Feature #15742: Add Date#jisx0301 support new Japanese era - Ruby trunk - Ruby Issue Tracking System () https://bugs.ruby-lang.org/issues/15742
[17] () http://www.mlit.go.jp/common/001223249.pdf
最も影響の大きそうなのが、「CALDATETIME構造が4つ以上の日本の元号を処理できない問題を修正」というものだろう。 この問題でいう「4つ以上の元号」を処理できないとは、この構造体を扱うAPI側の問題である(構造体自体に問題があるわけではない)。CALDATETIMEでは、明治からの元号に数字を割り当てているが、プログラム内で固定的に1~4を明治~平成と解釈しているため、令和(=5)を指定しても解釈されないという問題だ。
岩手日報、声の欄・8/5掲載の中に…
そこまで気にしなくてもいいでしょう…と感じるものがありました。
元号は崇拝な意味があるのに、
Hが付くと、性を想連想する…
[127] 令和の新元号発表のとき、 令和18年が 「R18」 (18禁) になる、といわれましたね。
やむを得ず年号区分コード「4:平成」で記録された場合であっても、
当分の間、「5:令和」として処理します。
[141] 年号一覧表, http://www.kumamotokokufu-h.ed.jp/kumamoto/bungaku/nengoui.html
さらに、これら拡幅による変化では解決できないのが、竣工年の違いである。
これがまた、昭和9年と大正9年という違い方が、憎たらしい。
数字の部分が一緒で年号だけが違っているのだが、「平成16年度道路施設現況調査」は年号を1~4の数字で表わしていて、1が明治、2が大正、3が昭和だが、この数字の誤記があれば容易く昭和と大正が入れ替わってしまう。
33,682 2020-01-11 14:00:29 /koneta/koneta_204.html 10
隧道の完成年の件 地元出身の長老から話を聞くことができました。大正15年生まれの方です。
幼少時代(就学前)浜へ遊びに行くとき通っていたそうです。そのことからすると完成は大正9年となります。 赤岩集落の ガン
[157] 3.4.21 LXRPID37 (年号コード変換(英字→数字)) : SEWB+/標準サブルーチン ライブラリリファレンス, , http://itdoc.hitachi.co.jp/manuals/3020/30203B8610/B860255.HTM
[88] THE IDOLM@STER MillionRADIO - 2022/12/22(木) 21:00開始 - ニコニコ生放送 () https://live.nicovideo.jp/watch/lv339271444
[166] Xユーザーの岩沼西小学校さん: 「駐車場としている校庭は、だいぶ水がたまっていますが、今来た方に聞くと、入口はだいぶ深くなってきているが、スタックするような状況ではないとのことです。 避難所では家族世帯にパーティションを使っていただいていますので御遠慮なくどうぞ。22:30現在まだ、スペースに余裕があります。 https://t.co/XONo6hIWxW」 / X, , https://twitter.com/iwanishisho/status/1183010587099287552/photo/3