2038年問題単語

ニセンサンジュウハチネンモンダイ

2038年問題とは、時刻を格納する変数オーバーフローによって引き起こされる事である。

概要

多くの場合、コンピュータの時刻の起点は1970年1月1日午前0時(協定世界時、つまりUTC)である。これをThe Epochと呼ぶ。一般にCでは時刻は32ビットの符号付整数に格納することにした。1ごとに1ずつ数字が増えるのでうるう秒を考慮しない場合(普通システムは考慮しない)、2038年1月19日午前3時14分7(UTC)に時刻がカンストしてしまう。そこから1が経過すると、1901年12月13日20時4552(UTC)になり、当然コンピュータが誤動作する。

対策は非常に簡単で、32ビットでオーバーフローしないようにしてしまうのが妥当なところである。

64ビットに拡張したときの日時の上限は

time_tがカンストする前に別の変数カンストしてしまう。それがstruct tmのtm_yearである。これは1900年からの年数をintで返す変数なのだが、int32ビット符号付整数なので、これが先にオーバーフローしてしまってでたらめな値を返す。

ほかの言語だとどうなるの

JavaScript・ActionScript

JavaScriptActionScriptでは、The Epochから1ミリ単位で管理する。その上限はうるう秒を考慮せずちょうど1億日である。つまり、2757609月13日午前0時(UTC)が管理できる上限である。そこから先は効な日時になってしまう。

Java

Javaの場合、日時はlong(符号付64ビット)の整数ミリ単位で管理する。ということは、それがオーバーフローしたバグを引き起こすわけだが、その時刻は2922789948月17日午前7時12分55.807が上限になり、それより先はオーバーフローして古生代くらいの時刻に戻ってしまう。

関連動画

この動画ゲームを使って非常にわかりやすく事を解説してくれている。
  

関連項目

【スポンサーリンク】

スマホ版URL:
https://dic.nicovideo.jp/t/a/2038%E5%B9%B4%E5%95%8F%E9%A1%8C

この記事の掲示板に最近描かれたお絵カキコ

お絵カキコがありません

この記事の掲示板に最近投稿されたピコカキコ

ピコカキコがありません

2038年問題

2 ななしのよっしん
2017/06/01(木) 21:16:41 ID: zin/e5XLJ3
2000年問題べ瑣末な問題
あのころとITに対する関心が桁違いだからなあ
まあ当時もPCが続々と入ってきた後で関心自体は高かった気はするが
3 ななしのよっしん
2017/09/11(月) 04:33:39 ID: zh2wY2Sp0v
>>2
楽観的にも程がある。
2000年問題と違って世界同時に発生するから決して瑣末とは言えない。
4 ななしのよっしん
2018/02/03(土) 02:48:15 ID: 5PV/XlyC8V
2038年問題2000年問題より深刻だと言われる所以は以下の通り

2000年問題アプリケーションレベルでの修正が可であったが、この問題は現在普及しているC言語理系OSAPIといったシステムの深いレイヤに潜む問題である。
32ビットの符号付2進表現におけるラップアラウンド」という理由を理解するには、ある程度の専門知識を必要とするので、一般大衆、経営者、政治家などの理解と関心を得にくい可性がある。(実際>>2みたいに専門知識がなければ瑣末な問題にしか見えないだろう)
2000年問題のように年の変わりというキリのよいときに地域の標準時に応じて順次に問題の時刻が世界を巡るのではなく、ごく中途半端な時刻に世界同時に一斉に問題の時刻が訪れるので、もし問題が生じた場合は対応するための人的資の確保がより困難となる可性がある。
5 ななしのよっしん
2018/02/07(水) 23:04:55 ID: hl20b6bulV
とりあえずバグスターが生まれるところまでは見えた
6 ななしのよっしん
2018/02/15(木) 01:19:37 ID: f2kNr5/OAw
OS64bit化してきたから壊れないかもしれんが
ファイルシステムext3とかopensslで生成する明書(既知のバグだが10年以上放置されてる)とか、
結構まだ2038年問題抱えてる仕様は残ってる。

32bitシステム視できないほどには健在で、
そういうシステムはそのときがくると一気に日付が140年近く戻ってタイマー起動する処理が一気に動くからか暫くフリーズするし

OSが対応していても、アプリケーションの保存ファイルに日付情報が入っているとヤバい
保存するときにテキスト形式で保存してるなら999912月31日までは大丈夫だろうけど、バイナリ形式で日付保存していると2038年問題が起きるかもしれない

下手にバイナリ64bit化して対応すると日付データサイズが変わって32bitアプリデータの互換性なくなるから困りもの

(省略しています。全て読むにはこのリンクをクリック!)
7 ななしのよっしん
2018/03/13(火) 03:29:57 ID: sm7T3pNGre
2038年1月19日12時14分7
8 ななしのよっしん
2018/03/20(火) 21:30:57 ID: ecECxmSVRe
関係ないけど
今年のにベリサイン/シマンテック系のSSL明書の大粛清来る(一部来た)ってのは聞いた
https://webtan.impress.co.jp/e/2018/01/30/28155exit

具体的にどう被害が出るかは何とも
9 ななしのよっしん
2018/12/21(金) 01:31:08 ID: 6CC+QVriBo
32ビットのospcを最近買ったばかりなのに…
10 ななしのよっしん
2019/05/02(木) 13:56:19 ID: 2reChhWIDO
せめて32bit符号しにしていれば、根本的な解決にはならないが、この問題を先送りにできたように思う。
11 ななしのよっしん
2019/06/17(月) 09:28:36 ID: L2Sl0XC6H+
>>10
それやると1970年より前の日付を全く扱えなくなるのでマズい

急上昇ワード