memorandumsスマートフォン用の表示で見るmemorandums日々の作業ログです。2038年問題2006-02-192038年問題プログラミング別件を調べていたときに「2038年問題」というキーワードを知りました。調べると2004年2月に日経コンピュータで特集されていたんですね。その記事によると以下のようです。UNIX環境では、システム内部の時刻をグリニッジ標準時(GMT)1970年1月1日0時0分0秒からの経過秒数で保持している。経過秒数で表す時刻データに、4バイトの符号付き整数を使っている場合には、2038年1月19日を過ぎると、本来数字の正負を判断するために使う部分まで時刻を表示するために使わざるを得なくなる。その結果、正しい時刻を認識できなくなるのである。リンク:日経コンピュータこの業界の方であれば、2000年の正月は大変だったと思います。前の会社でも上級職の方は交代で会社で留守番されていたのを覚えています。1999年は2000年を超えたときにシステムに何が起こりうるかシミュレーションを重ねていました。大変である一方、ビジネスにもなります。32年先ですが、まだ32年先だろう。いう発想(下二桁で十分)が2000年問題を生んだとも言えます。先が長い話というのは私自身含めなかなか実感できませんね。短い時間で管理するのが大切だということなのでしょう。タクト方式(トヨタ生産方式)。64ビットCPUが主流になるでしょうから、OSは問題なくなるでしょう。コンパイラもCPUやOSに追従できる。問題なのは現行稼動しているアプリケーション資産。Javaであれば、JVMが対応すればいいのでプログラムを変更する必要性はないでしょう。2038年問題を見越してプログラムを作っているようなことがなければ。日付が1970なら2039にするとか。リンク:20XX年問題特集!以下は間違いでした。ご指摘ありがとうございまいした。以下、試しに、Javaで2038年問題を実感してみました。1970年に戻ります。前期の授業も大詰めを迎えています。»プロフィールid:ke_takahashiソフトウェア開発、工作、面白ガジェットに興味があります。(1)はてなブログをはじめよう!ke_takahashiさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。