年問題

出典: フリー百科事典『ウィキペディア(Wikipedia)』
ナビゲーションに移動 検索に移動

年問題(ねんもんだい)は、暦上のある年や日付が到来すると、社会日常生活に深刻な影響が起きる社会問題のことである。「Y年問題」や「Y年M月D日問題」のように呼ばれる。年問題は主に下記の3種類のものがある。

  1. コンピュータの時刻処理における「桁溢れ」などの想定外の事態
  2. 人の動きや唐突な社会制度の変化による歪みの発生
  3. 暦そのものの構造的な欠陥(旧暦2033年問題など)

年問題という表現の発端は、コンピュータシステムにおける2000年問題が騒がれた出来事であり、それ以後は社会現象などの諸問題にも使われている。

コンピュータの時刻処理に関わる問題[編集]

コンピュータは記憶装置の容量や処理能力がいくら大きくとも原理的に有限の数字しか扱えず、想定していない日付を扱おうとした場合や、特定の年月日や時刻になった場合に誤作動を起こす(オーバーフロー、桁あふれ)。このシステム時刻処理に関する問題は、現代のように生活のあらゆる部分にITが行き渡っている時代には、思わぬところで思わぬ問題を起こしかねない。

日本で初めてコンピュータ内部の「年」に関する問題が起こったのは、1989年1月7日昭和天皇崩御によって元号が「昭和64年」から「平成元年」に変更された時である。特に公文書などで元号の変更を想定していなかったシステムが多数あったことから、問題が顕在化した。この他、年数を下2桁だけで処理していたシステムの中には、「昭和Y年」または「平成Y年」とみなして処理するものがあり、これにより誤動作が起きる場合もあった。

2000年問題(後述)では、事前に各企業が大量の経費を投入してシステムのチェックを行った上で、2000年が到来した瞬間には多数のソフトウェア技術者が何かあった時のために待機するなどの体制が取られ、世界的な社会現象となった。

なお年問題は、未来の日付を取り扱う必要が出てくると、その年に先んじて問題が顕在化することもある。例えば、10年更新の保険契約を扱う場合は10年前に誤動作が起こりうる。また、未来の日付を取り扱わない場合でも、計算の都合などで時間を数倍することがあり、それにより誤動作が起こりうる場合も存在する。

西暦[編集]

  • 1999年問題 - 1900年を1年目と内的処理していた場合、年数が2桁から3桁になる。また、年号を下2桁だけで処理していたシステムの一部で年のエントリで99をエラーコードや例外値として扱っている物があったとされ、そのようなシステムでは1999年になった途端に正当な1999年とエラーとを識別できず不具合をおこすことが懸念された。又、9が5つ並ぶ1999年9月9日にエラーが発生することも懸念された。
  • 1999年8月21日問題 - GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から1,024週後にあふれて0に戻る。
  • 2000年問題 (Y2K) - 年数を下2桁だけで処理していたシステムや、2000年平年閏年ではない)と誤解したシステムに問題が起こる。
  • 2001年9月9日問題 - 1970年1月1日0時からの秒数が十進法で9桁から10桁になる。経過秒数を文字列表現に直してソートしたことで、「1,000,000,000 < 999,999,999」と判断してしまい、項目の新旧が正しく処理されない問題が実際に幾つかのシステムで発生した。
  • 2004年1月10日問題 - 2038年問題の派生形で、1970年1月1日0時(Unix epoch)から2038年1月19日までの約21億秒の中間点にあたるこの日に潜在的なバグが発覚した。KDDIの通話料金処理、IIJSEIL/neuルーター、20行以上の日本国内銀行ATMで、同日または翌日以降にトラブルが発生した。CADソフト「Pro/ENGINEER」は1ヶ月前に誤動作の可能性を発見し、予め対処してトラブルを回避した[1]
  • 2008年問題 - 2000年以降も年数を下2桁だけで処理していたシステムで、かつ年を文字列で格納していた場合に、先頭が0の場合には八進数として扱われる処理系があり、その場合2008年の時点で年の処理が不正となる場合がある。ごく一部のperlで作成されたネットゲームで誤作動が発生した事例がある。
  • 2010年問題 - 潜在的なバグが発覚した。シチズン電波時計ソニーゲーム機プレイステーション3」(閏年処理)、オーストラリアクイーンズランド銀行でのシステム誤動作、ドイツジェムアルト社のICカード使用不能など。シチズンのケースでは、年の内部表現に西暦下2桁のBCDを使っていた。
  • 2019年4月7日問題 - GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から2,048週後にあふれて0に戻る。(10ビットでは2回目)
  • 2020年問題 - 2000年問題の1920年起点版。UNIXエポックの1970年1月1日±50年である1920 - 2019年date windowとしたシステムで誤動作を起こしている。
  • 2022年問題 - 日時をyymmddHHMMの形式で扱っているシステムで、この値を32ビット符号付き整数(最大値は2,147,483,647)に変換した場合、2022年1月1日にオーバーフローする。Microsoft Exchange Server 2016/2019で問題が発生した。
  • 2036年2月7日問題 - 1900年1月1日0時からの秒数が32ビットからあふれ、NTPに問題が起こる。NTPv4(バージョン4)以降では解決される。 
  • 2038年1月19日問題 - いわゆる2038年問題Unix等で、1970年1月1日0時(Unix epoch)からの秒数が31ビットからあふれ、32ビット符号付きで処理しているシステムに問題が起こる。ext2ext3ReiserFSUFS1XFS等の各ファイルシステムのタイムスタンプはこの日までしか扱えない。また、古い32ビット版のミドルウェアライブラリを利用したアプリケーションにも問題が発生しうる。
  • 2038年4月23日問題 - ユリウス通日を内部日付表現に用いる物のうち、基準日(グレゴリオ暦1858年11月17日正午)からの修正ユリウス日(MJD)を使用し、かつ16ビットで処理しているシステムでは、日数が16ビットからあふれるために問題が起こる。
  • 2038年11月21日問題 - GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から3,072週後にあふれて0に戻る。(10ビットでは3回目)
  • 2040年問題 - MacOS等のファイルシステムHFSタイムスタンプは2040年2月6日までしか取り扱えない。
  • 2042年問題 - System zのSTCK命令で取得する64ビットのTODクロックは2042年9月17日中にオーバーフローする。
  • 2048年問題 - 2038年問題の1980年起点版。
  • 2053年問題 - 2038年問題の1985年起点版。TRONなど。
  • 2079年問題 - FATファイルシステムのタイムスタンプの起点の1980年1月1日を基点として、年数を下2桁だけで処理するソフトウェアなどは、その起点の99年後(2079年12月31日)までしか正常動作しない。
  • 2100年問題 - 2000年以降に作られた年数を2桁で表すシステムや、2100年を閏年と誤解したシステムに問題が起こる。
  • 2108年問題 - FATファイルシステムタイムスタンプ2107年12月31日までしか取り扱えない。
  • 2137年問題 - 更新されたGPSは内部処理で週数を13ビットで管理しており、この頃にあふれて0に戻る(正確な日時は未定)。
  • 2155年問題 - ISO 9660ファイルシステム(CD-ROM等)のタイムスタンプ限度。
  • 2286年問題 - 2001年9月9日問題の11桁版。2286年11月20日17時46分40秒予定。
  • 2514年問題 - UNIX等のファイルシステムext4のタイムスタンプ限度。2514年4月25日予定。
  • 3000年問題 - Visual C++において、3000年1月1日以降の日付処理に不具合が生じる。
  • 10000年問題 - 西暦が5桁になる西暦10000年1月1日に起こる。
    • Excel,Google スプレッドシートの日付処理で不具合が生じる。
    • UDF(光ディスク等)のタイムスタンプ限度(9999年12月31日まで)。
  • 32768年問題 - LibreOffice CalcやWindowsのシステム[要出典]では西暦は16bit符号付きで表すことができるが、32768年にオーバーフローを起こす。
  • 60056年問題 - NTFSのタイムスタンプ限度。
  • 2億9千万年問題 - 292278994年8月17日以降Javaの日付処理に問題が生じる。
  • 2922億7702万6596年問題 - 64ビット符号つきUNIXシステムの上限は292277026596年12月4日15時30分7秒まで。ただし、2013年時点では宇宙の年齢は137億年程度と考えられている。

他の紀年法[編集]

  • 昭和100年問題2025年) - 2025年は、内部で年を昭和2桁で管理するシステムでは「昭和100年=昭和0年」と認識され、問題が起こる。
  • 皇紀2700年問題(2040年)- 2000年問題と同じく、システム内部で年を皇紀の下2桁で管理するシステムにおいて、問題が発生する。
  • 平成100年問題(2088年) - 昭和100年問題と同じく、2088年が「平成100年=平成0年」と誤認されることにより、内部で平成2桁で管理されているシステムに問題が起こる。
  • 令和100年問題(2118年) - 昭和100年問題平成100年問題などと同じく、2118年が「令和100年=令和0年」と誤認されることにより、内部で令和2桁で管理されているシステムに問題が起こる。
  • 民国100年問題民國100年問題Y1C) - 中華民国台湾)で使用している民国紀元2011年が民国100年となることによる問題。

関係する他の問題[編集]

  • 閏年問題 - 閏年を処理するプログラムのバグにより誤動作する。2008年1月31日以降、日本の約3200台の公衆電話が閏年問題による障害で一時的に使用不能となった。
  • 閏秒問題 - 閏年問題の閏秒バージョン。こちらもプログラムのバグにより誤動作する。

社会問題[編集]

以下は、正確にその年が問題となるものもあるが、数年にわたる現象のピークを示すものや、統計上興味深い変化が予想される場合など、その年に実際に何かが起こるわけではないものもある。また、事前の予測年と事象の実際の発生年が異なった場合や、その事象に関する関係者らの事前の対策や努力などで回避・先送りできたり、あるいは過去に問題の発生が予測・懸念されても、その後の社会の変化などで実際には問題は起こらず単なる杞憂に終わった事象もある。

世界[編集]

日本[編集]

実際に起こった・かつて起こるとされた問題[編集]

予想される問題[編集]

暦の構造による問題[編集]

脚注[編集]

[脚注の使い方]
  1. ^ xTECH(クロステック), 日経. “「西暦2038年問題」でトラブル相次ぐ” (日本語). 日経 xTECH(クロステック). 2019年2月18日閲覧。
  2. ^ 当該PCののSDRAMメモリ搭載上限が1GBであるなど
  3. ^ 東京都区部におけるオフィスビルの需給動向について (PDF) - 国土交通省
  4. ^ INC, SANKEI DIGITAL. “東京「2019年問題」!? 大型展示場は軒並み五輪で使用 モーターショー、コミケはどうなる?” (日本語). 産経ニュース. 2018年12月11日閲覧。
  5. ^ より正確には、INSネット64・INSネット64ライト・INSネット1500のディジタル通信モードが提供終了となる。詳細は「INSネット」参照。
  6. ^ 2024年問題とは?EDI再構築のポイント” (日本語). ASCII.jp. 2021年10月11日閲覧。
  7. ^ EDIの2024年問題とは? ISDN回線終了で何がどうなるか” (日本語). キーマンズネット. 2021年10月12日閲覧。
  8. ^ 2025年問題”. 一般社団法人ディペロップメントシニアPCコミュニティ. 2018年1月7日閲覧。
  9. ^ デジタルトランスフォーメーションに向けた研究会. “デジタルトランスフォーメーションに向けた研究会の報告書『DXレポート~ITシステム「2025年の崖」の克服とDXの本格的な展開~』”. 経済産業省. 2018年12月11日閲覧。
  10. ^ 松田卓也『2045年問題 コンピュータが人類を超える日』廣済堂出版 2012年 ISBN 978-4331516836

関連項目[編集]

外部リンク[編集]