Edit

Page

Page title:

Page body:

[4] 
[DFN[100年問題]]は、
[[年号]]を[[2桁][2桁年号]]で表す[[日時形式]]を扱うシステムに関する[[日時桁溢れ問題]]です。

[1] 
[[日本]]では[[昭和100年問題]]が有名ですが、他に[[平成100年問題]]、
[[民国100年問題]]が知られています。

[573] 
[[2桁年号問題]]の1種であるという点は[[西暦2000年問題]]と同じ性質を持ちます。
一方で、「本来4桁のものを2桁で表した」
という設計ミスに起因する[[西暦2000年問題]]とは違う性質も持っています。

* 100年問題共通の性質

[7] 
[[100年問題]]は、[[年]]を[[10進数]]2桁の[[非負整数]]で扱うシステムの[[日時桁溢れ問題]]です。

[8] 
[[日時桁溢れ問題]]は、[[日時構成要素]]がシステム上取り扱い可能な[[値域]]を超過することに関する諸問題です。
[[日時桁溢れ問題]]一般の性質については、[[日時桁溢れ問題]]を参照。

[9] 
具体的には、[[年]]が100年になると2桁で表せなくなって問題が起こります。

[10] 
また、 [CODE[99]] を「未知」「未定」「不明」など特別な意味に割り当てられていることがしばしばあり、
その場合は100年より前に発症します。

[11] 
更に、[[将来の日時]]を扱う場合 (予定の登録など) は、その[[年]]に到達する前に発症します。

-*-*-

[2] 
特殊形として、
本来3桁以上の[[年]]を[[無理に2桁で表現した場合][2桁年号]]の[[100年問題]]もあります。
特に[[西暦2000年問題]]は当時社会問題となりました。
[SEE[ [[西暦2000年問題]], [[皇紀2700年問題]] ]]

* 昭和100年問題

[106] 
[DFN[昭和100年問題]]は、
[[昭和]]の2桁[[年号]]の[[日時形式]]を扱うシステム
([SEE[ [[昭和暦]] ]])
に関する[[日時桁溢れ問題]]です。

[441] [CITE@ja[オヤジ戦隊ダジャレンジャー@オンラインサロンやって〼色々開発ちうさんはTwitterを使っています 「昨夜汎用機系の友人から電話があり、彼の担当現場では未だに #昭和100年問題 を解決できず「現場にも会社にも見切りをつけた」と言っていた。 ワシが前職を退職したのも、32bitコンパイラのShiftJISでネット対応の無理ゲーを迫る #2038年問題 を理解しない会社だったからだ。 https://t.co/ikgRr3FOti」 / Twitter]], [TIME[2022-02-13T02:50:18.000Z]], [TIME[2022-02-13T03:20:16.762Z]] <https://twitter.com/dajya_ranger_/status/1490264002131288064>

** 西暦2000年問題と昭和100年問題

[14] 
[[昭和100年問題]]は、[[西暦2000年問題]]の頃にも注目されました。
いずれ同じように問題になり対策が必要だと注意喚起されました。

[15] 
[[西暦2000年問題]]の対策として[[昭和]]の2桁の表現に切り替えたシステムもあったといわれています。
(性質上、それがどれくらい行われたのか知ることは難しいですが...)

[16] 
問題の先送りに過ぎないとの批判もありましたが、先送りで問題が当面解決するならそれでよいという考え方もあります。
この種の問題で一体何が「本質的な解決」といえるのかは難しく、
西暦4桁で表したところで[[西暦10000年問題]]に先送りしたに過ぎないのです。
[SEE[ [[日時桁溢れ問題]] ]]
結局これは[[無限]]の世界を現実のシステムに落とし込むバランス感覚が問われているもので、
経済性と設計センスの[[工学]]論に帰結します。

[20] 
[CITE@ja[損害保険システムの昭和100年対応案件 | COBOL 大阪府 単価 月額 ~40万円 | エンジニアファクトリー(フリーランス)]], [TIME[2024-06-07T06:52:06.000Z]] <https://www.engineer-factory.com/freelance/jobs/100012411>

>和暦3桁(元号+年2桁)で保持している日付項目に対して、年2桁項目を10進から16進に変換を行う対応

** 昭和100年問題をめぐる誤解

[420] 
「[[日時]]の[[内部表現]]で[[平成改元]]以後も[[昭和の年数を使う][昭和の延長年号]]こと」
([SEE[ [[昭和暦]] ]])
と
「昭和の年数を2桁整数で扱うシステムで昭和100年を迎えること」
は、
まったく別個の問題です。
後者は[[西暦2000年問題]]と同種の問題ですが、
前者はシステム設計上の合理的な選択肢の1つでこれといった問題は知られていません。

[421] 
[[昭和100年問題]]を扱う記事や[[SNS]]への投稿を見ると[[情報処理]]実務の専門家でもこの2つの区別がついていない人が意外に多い
[SRC[>>419]]。

[423] 
前者、つまり[[日時]]の内部表現は、例えば

- システム内部で[[日時]]を [[Unix time]] で表し、必要に応じて[[西暦年]]を計算して表示する
- システム内部で[[日時]]を [[Unix time]] で表し、必要に応じて[[昭和]]、
[[平成]]、[[令和]]などの[[年]]を計算して表示する

... といったシステムがごくごく一般的に存在するのと同じように、

- システム内部で[[年]]を昭和元年を1とする[[整数]]で表し、必要に応じて[[西暦年]]を計算して表示する
- システム内部で[[年]]を昭和元年を1とする[[整数]]で表し、必要に応じて[[昭和]]、
[[平成]]、[[令和]]などの[[年]]を計算して表示する

... といったシステムも存在し得ますし、実際に存在しています。
[[Unix time]] も昭和元年を1とする[[整数]]も、単位と[[基準点][元期]]が違うだけで、
処理内容は本質的に変わりありません。どちらの設計を採用するかは、
目的に応じてどちらが都合が良いか、いわば設計センス次第です。

[424] 
昭和元年を1とすることだけを理由にその設計を批判するのだとしたら、
その批判のほうがむしろセンスがないと言わざるを得ません。

[17] 
まあ社会的には[[昭和]]が終わって[[平成]]になっているのに、
システム内部で[[昭和]]の年数が使われ続けているとすると、
なんだかおかしいという感覚自体は理解できないでもありません。
そのような違和感を抱く人が多いのは、
それだけ[[元号]]というシステムが日本社会に深く根付いている1つの傍証ともいえます。
そうでなければ[TIME[西暦1901年][1901]]が1年となる[[西暦1900年暦]]や、
[TIME[西暦1970年][1970]]に [N[0]] がある [[Unix time]] 
と同等でしかない「[TIME[西暦1925年][1925]]が1年となる[[紀年法]]」
で動くシステムがおかしいと考える人はいなかったことでしょう。

[REFS[
- [107] [CITE@ja[昭和100年問題 - Wikipedia]]
([TIME[2018-04-19 01:04:51 +09:00]])
<https://ja.wikipedia.org/wiki/%E6%98%AD%E5%92%8C100%E5%B9%B4%E5%95%8F%E9%A1%8C>
- [108] [CITE@ja-jp[昭和100年問題 ‐ 通信用語の基礎知識]]
([TIME[2018-04-23 23:55:55 +09:00]])
<http://www.wdic.org/w/TECH/%E6%98%AD%E5%92%8C100%E5%B9%B4%E5%95%8F%E9%A1%8C>

[FIG(quote)[
[FIGCAPTION[
[109] [CITE[「「2025年問題」に備えていますか?」 | 株式会社オージス総研]]
([TIME[2017-10-25 09:54:44 +09:00]])
<http://www.ogis-ri.co.jp/rad/webmaga/rwm20130802.html>
]FIGCAPTION]

> 「2025年問題」をご存じですか? 実は「2025年問題」と言われているものには、いくつかありまして、2025年は昭和元年からの換算ではちょうど100年となり一部のコンピュータシステムで問題が発生する件を指すこともあれば、団塊の世代が75歳以上に達し、厚生労働省の社会保障給付総額が144兆円になってしまう問題を指すこともあります。

]FIG]

- [110] [CITE@ja[「残り6年」…新元号対応よりもヤバイかもしれない「昭和100年問題」というのがあるらしい…「絶望やんけ」 - Togetter]]
([TIME[2019-01-16 14:14:16 +09:00]])
<https://togetter.com/li/1308910>
- [111] [CITE@ja[改元対応よりも大変? IT業界でうわさの「昭和100年問題」とは - ITmedia NEWS]]
([TIME[2019-03-20 12:51:07 +09:00]])
<https://www.itmedia.co.jp/news/articles/1903/06/news020.html>

[413] [CITE@ja[パソコン・ソフト:詳細資料A - リコーの西暦2000年問題対応について]], [TIME[2020-12-08T04:07:45.000Z]], [TIME[2021-06-08T03:50:56.160Z]] <http://radioc.web.fc2.com/weblib/y2k/ricoh/a.htm>

>
Q6.データのフォーマットを変更できないので、既に入力されている日付データを簡単に西暦(下2桁)運用から和暦運用への変更する方法は有りますか。
>
A6.C命令を利用し、西暦を和暦に変更できます。
日付列—88=日付列
例.98(西暦)—88=10(和暦)
その他、SHU命令やUPD命令を利用して、西暦を和暦に変更できます。

- [419] [CITE@ja[2025年に起こる事が懸念される日本特有の『昭和100年問題』というものがあるらしい「“延長昭和”という暦を採用しているシステムが火を噴く」 - Togetter]], [TIME[2021-10-14T02:00:58.000Z]] <https://togetter.com/li/1788182>
]REFS]

-*-*-

[422] 
ついでに、この話題になると[[和暦]]を廃止して[[西暦]]にしろとか技術と関係ない[[政治的主張を始める人][元号廃止論]]も必ず何人か湧いてきます
[SRC[>>419]]。

[12] 
システム内部の日時表現の選択と、
社会的な[[紀年法]]の約束は、判断基準が異なる独立した話で、
混同してはいけません。
社会的に[[和暦]]が消滅しても、
[[昭和100年問題]]が解決するわけでも、
[[西暦]]が最も処理しやすい内部表現になるわけでもないのですが。。。

;;
[13] 
それが分からないなら技術的に知識不足ですし、
分かっているなら政治のダシに技術を使っているので、
どちらにしてもダメですね。

** 作品

-[445] [CITE@ja[【[[ムー]]2025年の危機】コンピューターに隠された亡霊「昭和100年問題」の真実 | GetNavi web ゲットナビ]], 
[[嵩夜ゆう]],
2019/11/2 20:15,
[TIME[2022-05-26T02:37:43.000Z]] <https://getnavi.jp/entertainment/440216/>
--「ムー2019年11月号より抜粋」

[446] 内容はめちゃくちゃ (まあ[CITE[ムー]]なんで...)

[572] 
[CITE@ja[ITコメディアニメ「こうしす!」アンコール企画&総集編映画で新たなステージへ! - CAMPFIRE (キャンプファイヤー)]], [TIME[2024-05-09T12:22:48.000Z]] <https://camp-fire.jp/projects/view/741097?utm_source=twitter&utm_medium=social&utm_campaign=tw_po_share_c_msg_projects_show>

>昭和100年には、昭和の年号で動き続けているシステムが桁あふれにより誤動作を起こす可能性が指摘されています。これは「昭和100年問題」と呼ばれています。こうしす!アニメ版でも第1話から伏線として示されており、その伏線を回収するための小説を執筆します。

>総集編映画の各メディアへの持ち込みは2024年内に行い、2024年内の展開を目指します。
>
また、2025年(昭和100年)1月~春ごろからの配信を目指します。

** 関連

[18] 
[[昭和]]を使い続けること全般については[[昭和の延長年号]], [[昭和暦]]を参照。

[19] 
昭和100年記念については[[昭和100年]]を参照。

* 平成100年問題

[119] [CITE[Wikipedia]] などは[DFN[平成100年問題]]を指摘しています
[SRC[>>117]]。実在するかは不明です。

[548] [CITE@ja[Xユーザーのichiro_jさん: 「平成2桁はあるけど昭和2桁はもう身近にはないな」 / X]], [TIME[午後0:34 · 2024年1月1日][2024-01-01T03:34:07.000Z]], [TIME[2024-01-01T06:38:38.000Z]] <https://twitter.com/ichiro_j/status/1741664068103229467>

[549] あるのかー・・・

[REFS[

- [117] [CITE@ja[[[年問題]] - Wikipedia]]
([TIME[2018-04-19 01:05:26 +09:00]])
<https://ja.wikipedia.org/wiki/%E5%B9%B4%E5%95%8F%E9%A1%8C>

]REFS]

* 民国100年問題

[112] [DFN[民国100年問題]]は、
[[民国紀元]]の2桁[[年号]]の[[日時形式]]を扱うシステムに関する[[日時桁溢れ問題]]でした。

[115] [[特許番号]]は固定長に見えてそうではなく、
3桁に拡張されたようです。

[REFS[
- [113] [CITE@ja[民国100年問題 - Wikipedia]]
([TIME[2018-04-09 23:49:25 +09:00]])
<https://ja.wikipedia.org/wiki/%E6%B0%91%E5%9B%BD100%E5%B9%B4%E5%95%8F%E9%A1%8C>
]REFS]

[447] [CITE@zh-Hant-tw[公元2000年資訊錯亂危機]], [TIME[2022-05-28T22:17:40.000Z]] <https://www.tfrin.gov.tw/News_Content.aspx?n=307&s=29011>

[448] [[西暦2000年問題]]当時の紹介記事。西暦4桁化により民国100年問題も同時解決できると述べている。

[473] [CITE@en-US[Taiwan’s Y1C problem | Pinyin News]], [TIME[2023-01-01T10:11:51.000Z]] <http://pinyin.info/news/2006/taiwans-y1c-problem/>

[474] [CITE@zh[民國百年蟲 - 维基百科,自由的百科全书]], [TIME[2022-12-18T10:10:47.000Z]], [TIME[2023-01-01T10:12:02.859Z]] <https://zh.wikipedia.org/wiki/%E6%B0%91%E5%9C%8B%E7%99%BE%E5%B9%B4%E8%9F%B2>

[475] [CITE@ja[民国100年問題 - Wikipedia]], [TIME[2022-12-25T16:08:57.000Z]], [TIME[2023-01-01T10:12:10.935Z]] <https://ja.wikipedia.org/wiki/%E6%B0%91%E5%9B%BD100%E5%B9%B4%E5%95%8F%E9%A1%8C>

[476] [CITE@en[Year 2011 problem - Wikipedia]], [TIME[2022-12-29T19:06:00.000Z]], [TIME[2023-01-01T10:12:19.204Z]] <https://en.wikipedia.org/wiki/Year_2011_problem>

* 関連

[3] 
一部の欧米人は[[令和改元]] (に伴うシステム改修) を「日本版Y2K」のように表現しました。
[SEE[ [[令和改元]] ]]
しかし「日本版Y2K」のようなものがもしあるとするなら、
[[昭和100年問題]]や[[皇紀2700年問題]]の方がその名により相応しいといえます。

[5] 
民国100年は主体100年でもありましたが、[[朝鮮民主主義人民共和国]]ではそのような問題は知られていません。
問題が起こらなかったのか、伝わらなかったかは不明です。
[[主体]]が公用され初めたのは[TIME[西暦1997年][1997]]です。
およそそれ以後に開発されたシステムでは[[主体]]の2桁年を使っていても不思議ではありません。

;;
[6] 
他の諸国では[[西暦2000年問題]]が話題になり初めていた時期ですし、
20年も待たずに主体100年を迎えるときにそんな設計には普通はしないだろうとは思うのですが、
欧米や日本の事例 ([SEE[ [[日時桁溢れ問題]] ]]) を参照すると
「あり得ない設計」は普通にあり得るものですので...

* メモ

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Errors

Page name(s)