「2038年問題」の版間の差分

提供:MonoBook
ページの作成:「2038年問題とは、2038年に「16ビットの修正ユリウス通日」と「32ビットのUNIX時刻」がオーバーフローするという2種類の問題の…」
 
編集の要約なし
 
(同じ利用者による、間の1版が非表示)
7行目: 7行目:


== 32ビットのUNIX時刻 ==
== 32ビットのUNIX時刻 ==
32ビットのUNIX時刻も2038年1月19日3時14分7秒(閏秒を考慮しない場合)に[[オーバーフロー]]するという問題を抱えています。
32ビットの[[UNIX時刻]]も2038年1月19日3時14分7秒(閏秒を考慮しない場合)に[[オーバーフロー]]するという問題を抱えています。


UNIX時刻は主に高性能な[[コンピューター]]で使われているものなので修正は簡単そうに見えますが、そもそもメンテナンスできる技術者が既にいないなどの問題があるようです。そんなシステムさっさと捨てましょう。
[[UNIX時刻]]は主に高性能な[[コンピューター]]で使われているものなので修正は簡単そうに見えますが、そもそもメンテナンスできる技術者が既にいないなどの問題があるようです。そんなシステムさっさと捨てましょう。
 
<amazon>2038年問題</amazon>

2024年10月1日 (火) 12:41時点における最新版

2038年問題とは、2038年に「16ビットの修正ユリウス通日」と「32ビットのUNIX時刻」がオーバーフローするという2種類の問題の総称です。この2つは異なる問題ですがどちらも2038年問題と呼ばれています。

16ビットの修正ユリウス通日[編集 | ソースを編集]

修正ユリウス通日を日付の表現に採用している処理系の多くは、そのデータ長に16ビットを用いており、16ビットで表せる整数の最大値である65535(0xFFFF)になる2038年4月22日を超えるとオーバーフローが発生してしまうという問題です。

修正ユリウス通日はリソースに乏しいワンチップマイコンなどの組込機器で多く採用されている形式であり、書き換えもパソコンほど容易ではないと言われています。状況としては年数の表現をグレゴリオ暦の下二桁のみで表していたことによる2000年問題に近いものと言われています。

32ビットのUNIX時刻[編集 | ソースを編集]

32ビットのUNIX時刻も2038年1月19日3時14分7秒(閏秒を考慮しない場合)にオーバーフローするという問題を抱えています。

UNIX時刻は主に高性能なコンピューターで使われているものなので修正は簡単そうに見えますが、そもそもメンテナンスできる技術者が既にいないなどの問題があるようです。そんなシステムさっさと捨てましょう。