サイト内の移動
最新投稿
当年度ブログの検索
カレンダー
S M T W T F S
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
<<  2025 - 05  >>


2025 - 1 2 3 4 5 6 7 8 9 10 11 12
2024 - 1 2 3 4 5 6 7 8 9 10 11 12
2023 - 1 2 3 4 5 6 7 8 9 10 11 12
2022 - 1 2 3 4 5 6 7 8 9 10 11 12
2021 - 1 2 3 4 5 6 7 8 9 10 11 12
2020 - 1 2 3 4 5 6 7 8 9 10 11 12
2019 - 1 2 3 4 5 6 7 8 9 10 11 12
2018 - 1 2 3 4 5 6 7 8 9 10 11 12
2017 - 1 2 3 4 5 6 7 8 9 10 11 12
2016 - 1 2 3 4 5 6 7 8 9 10 11 12
2015 - 1 2 3 4 5 6 7 8 9 10 11 12
2014 - 1 2 3 4 5 6 7 8 9 10 11 12
2013 - 1 2 3 4 5 6 7 8 9 10 11 12
2012 - 1 2 3 4 5 6 7 8 9 10 11 12
2011 - 1 2 3 4 5 6 7 8 9 10 11 12
2010 - 1 2 3 4 5 6 7 8 9 10 11 12
分類
月別の記録
状態
現在: ゲストモード

昭和100年問題なんて起きなかった オカルト話とごく一部の対応
 頭のご不自由なオカルト系が2000年問題かのよう日本では昭和100年で狂うなんて吹聴した。ノストラダムスやマヤを勝手に滅亡予言にしたオカルト連中の戯言でしょ。

 一般のパソコンでは西暦2000年問題も昭和100年問題も無い。UNIXに準拠して作られた古いパソコンにあるのは2038年問題だった。それは日付時刻を1970年を基点に32ビット(4バイト)符号付き整数を使った秒数でカウントしてるから世界標準時2038年01月19日03時14分07秒 にて桁あふれにてマイナスの最大値になるため1901年に戻ってしまう。

 今のパソコンとOSで時刻は64ビット(8バイト)に拡張されてるから1000年は使える。だが過去に作られたプログラムを使う限り2038年問題は消えない。私が過去に作ったのは未対応だが長年と使う目的じゃなくお払い箱であり、問題が生じるプログラムは使ってた企業ごと消滅してる。名前を言えば大勢が知ってる企業が運営してたエステティックサロンの顧客管理ソフトを作ったが昔話。

 4バイトで管理できるものをストリング(テキストデータ)で記録すると年月日でも8バイトも必要になってしまう。そこを1900年代には6バイトにしたから2000年問題ってのが出た。自分が設計したのを思い出すと年・月・日ごと分離したりストリングでは記録してない。だがtime関数でやり取りする long が4バイト長のため 2038年問題は生じる。

続きを読む ≫


そこから調べてみると各種データベースによって基点となる年月日が違っていた。

 日本製PCだって和暦なんかで動作してないが、データベースで管理してるのを和暦なんてのにしてたら既に「平成」もあったのだから年号を使っていたとすれば改修しており、西暦2000年問題より前に「昭和」は終わってるわけで昭和100年で桁あふれなんて意味がわかりません。

 俺は思う。例え役所から発注を受けたとしても内部は西暦で管理してるはず。そうしないと年齢とか管理するのが大変になる。昭和は長かったが今なら年号をいくつも渡ってる人達が多い。連続した年月日の数値で計算処理しないとプログラミングが大変だ。

2038年問題は2000年問題より恐ろしく何十年も使い続けてる分野は改修が必要。



 それにも関わらず年号を使って情報を記録していたとして、年号のために2ビット(0から3)しか割り当てず「明治」「大正」「昭和」「平成」にて足りなくなったなら話はわかるが、そんなの何十年も昔に作られたデータではなかろうか。私が社会に出たての小僧の頃でも記録容量は少なく、特にパソコン側のメモリーの少なさから節約する必要を迫られビットで管理しろと言われた。もう先々のことを考えて作ってるはず。

 変な時代になった今なら問題だろうが生物学的な性別を記録するなら1ビットで足りる。その程度に1バイト使うとプログラミングが楽になるだけ。今ならテキストデータくらい使い放題だけど昔に郵便番号7桁あったら住所データ量を節約できたな。でも都道府県は6ビット(0~47)で分別できるため節約できた。郵便番号が3桁の時代では重複する市町村が多すぎた。



 お役所仕事なら非論理的な年号が基本であり、加えて4月始まりの年度と誤解を生じることばかり。冒頭が "IDENTIFICATION DIVISION" なんてのは学生時代に始まり学生時代に終わった。金融系の仕事をすることはなかったからね。今でも残ってるのが怖くもある。

 そんなプログラム言語じゃなくても人間のほうが落ちぶれてしまったし、不況、リーマンショックなどから企業が検査費用を削減してしまったと同時にインターネットの普及が加速したため気軽に「ネットで更新」と企業側が障害を発生させる責任に無頓着になってしまった。私はROM化するソフトを作っていたため最初からアセンブラだったりコンパイルしたコードを追ってレジスタの値を調べることまでやってた。



 先日は高速道路の決済システムであるETCが障害で長時間の停止は報道によると更新したプログラムがバグってた。それより遡っても色々と人為的なシステム障害を起こしてる。今どきの奴らのする仕事。

俺なんか下請けだけど実働要員だ。バグ満載のくせに偉そうなクチを叩く企業と社員には呆れる。

≪ 続きを隠す
| emisaki | 2025-05-05 Mon 23:57 | 生活::コンピューター・電気 関連 |