  |
はてなキーワード: 2000年問題とは
元増田です。
記事を見て愕然としました。2015年のマイナンバーカード発行開始の時は忙しかった印象があったのですが、普及率はさほどではなかったのですね。
2018年にようやく普及率10%に届いたくらいで、2015年は少なすぎてグラフに載るほどでもなかったのですか。
これなら2025年になったとしても電子証明書の更新で多少は込み合うことはあっても、10年に一度のカード更新でさらなる混雑を生むことはなさそうですね。
2025年問題などと過去にあった2000年問題にかこつけて、時代の先を読む先導者や軍師を気取っていた自分が恥ずかしいです。
市役所に務めているにもかかわらず、公開されている統計情報を読まずに自分の主観的な感覚で物事を判断していたことにただただ反省するばかりです。
昔見たときは「自分の仕事に意味があると思い込もうとする」ということが、狂人の仕草に見えたが、今となってはそれも良くわかる。分かるようになってしまった。
話の中では、銀行で2000年問題に取り組んだサラリーマンたちは、自殺・精神病・自暴自棄？に追い込まれていて碌なことになっていない。彼らは「意味のない仕事に追い詰められ、捨てられた」象徴に過ぎない。
社会の枠組みからはみ出て自由に生きる濱マイクと、社会の歯車としてすり潰される人間との残酷な対比か。それだけにマイクの奔放さが輝いて見える。
そうすると、オープニングとエンディングに突然出てくる「迷い牛」は、社会に飼い慣らされたサラリーマンの暗喩ということになるか。すっかり牛側になったからこそ、理解できてしまう。
以前は何か独立した装置で行っていて、2000年問題(!)の際にAccessに切り替えたそうだ。
しかし、新しいAccess（弊社ではAccess2016）を使用してMDBファイル（Access2000-2003データベース）の最適化を行った時にレコードが消失するバグがあった。
消える量は微々たるものであるが、最適化のたびにランダムでデータが消えるのではデータベースとしては役に立たない。
このバグについて調べるにあたって、偶然会社の倉庫に眠っていたAccess2007を発見し、それで検証してみたところものすごい量のデータが消失していた。2007環境で作業していた人はおかしいと思わなかったのだろうか？（社内でAccessはこの在庫管理にしか使っていない）
2016で同様の検証をしてもなかなか消失は確認できなかったが、実務上確実にデータが消えていることを時折確認している。これは最新バージョンで解消されているそうだが、会社のPCであるのでアップデートの適用が随時は行われず、４か月遅れであるようであった。
ただ、4か月遅れとはいえ時折バージョンアップされているにも関わらずバグが解消される気配が全くないまま業務を行っていたのだが、いい加減やってられないのでやむを得ずAccess2019を導入することとした。このあたりについて調べている時、そもそもバージョンアップ内容のアナウンスがかなり複雑に隠されていたり、アナウンスされていなかったりとMicrosoftの不親切さを痛感した数時間だった。
ただし、Access2019にアップグレードしたからといってバグが解消される確信はなかった。
私はそもそもMDBなどという古い形式で強行するのはやめたい、システム的にも古い上に個人のエンジニアが開発したものであり、古いからではなくそもそもの造りにバグが多く、現在弊社の事業規模に見合ったサポートを受けられていないことから、システムそのものを更新して欲しいと上申し続けている。
というか2000人を抱える大企業でこんな古い（しかもバグを抱えた）データベースに頼っているってどうなの？
しかしなかなか承認を得られないため、やむをえず応急処置的に最新版である2019を導入することとした。
データベース管理に使っているPCにはボリュームライセンス版のOffice2016がインストールされている。
ここにAccess2016を個別に購入し、インストールしている。
ライセンス的にはOffice2016とAccess2016は別であるが、同じ2016同士なので共存できているようだ。
ここにAccessのみ2019をインストールしてみようとしたが、Office2016がインストールされているためインストールできませんとなってしまった。
以前、別の会社にいた時に2003と2010か何かは共存させた気がするのでできると思っていたが、起動のたびにオンライン認証しているからだろうか。今はもう無理らしい。
そもそもボリュームライセンス版のAccess2019（Office2019）のインストールは非常に面倒くさい。
いわゆるインストーラではなく、コマンドプロンプトからのインストールである。GUI環境を創造し、推進してきたMicrosoftが、この2019年になってCUIを持ち出してきたのだから驚きだ。
このあたりは調べたらいろいろ有意な情報がたくさんでてくるので、そちらを参考にしてもらいたい。
ちなみにConfiguration.xmlの作成は非常に面倒であるが、Microsoftが提供している、質問に答えていくだけで作成してくれるものを使うのが一番楽にできる。
リモートがオンになっているとインストールに支障があるというのも謎だ。
バグに対しても、Office2016とAccess2019の共存についても解決できていないが、もしこの記事を見て何か思い当たる点がある人がいれば連絡をください。
考えるとこんな感じ？
中小企業とかマクロ組んでるトコは大変だと思うけどどうなんかね。
元号ってシステムが今上の陛下に依存しちゃうものだから、対応は後手になるのは仕方ないんじゃない？もし改元の前に崩御されたら、次の年号が決まる間どうすんのよとかあるよね。多分、後から訂正するんだろうけど。
この問題が、もう2000年問題前後の15〜20年くらい早かったらもちっと色々対策を考えられたんだろうけど(ITバブルだし)、対応が膨大だーって言う人は言ってることがぼんやりしていて分かんないんだよね。おめーの会社のシステムの実装なんかしらねぇよって。
元号について全く考慮に入れてない設計なら設計したSEはSE失格だし(業務系なら必須だし、そうでないなら西暦使えばいい)、考慮に入れてるけどテストが大変です、なら、じゃあ、お客様といつまでに対応しますで終わりな気もするのよね。
1900年を1年目と内的処理していた場合、年数が2桁から3桁になる。また、年号を下2桁だけで処理していたシステムの一部で年のエントリで99をエラーコードや例外値として扱っている物があったとされ、そのようなシステムでは1999年になった途端に正当な1999年とエラーとを識別できず不具合をおこすことが懸念された。又、9が5つ並ぶ1999年9月9日にエラーが発生することも懸念された。
GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から1024週後にあふれて0に戻る。
年数を下2桁だけで処理していたシステムや、2000年を平年(閏年ではない)と誤解したシステムに問題が起こる。
1970年1月1日0時からの秒数が十進法で9桁から10桁になる。経過秒数を文字列表現に直してソートしたことで、「1,000,000,000 < 999,999,999」と判断してしまい、項目の新旧が正しく処理されない問題が実際に幾つかのシステムで発生した。
2000年以降も年数を下2桁だけで処理していたシステムで、かつ年を文字列で格納していた場合に、先頭が0の場合には八進数として扱われる処理系があり、その場合2008年の時点で年の処理が不正となる場合がある。ごく一部のperlで作成されたネットゲームで誤作動が発生した事例がある。
潜在的なバグが発覚した。シチズン電波時計やソニーのゲーム機「プレイステーション3」(閏年処理)、オーストラリアのクイーンズランド銀行でのシステム誤動作、ドイツジェムアルト社のICカード使用不能など。シチズンのケースでは、年の内部表現に西暦下2桁のBCDを使っていた。
GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から2048週後にあふれて0に戻る。(10ビットでは2回目)
1930年 - 2029年を下2桁で表現しているシステムに問題が起こる。同様のものに2050年問題や2070年問題などがある。
1900年1月1日0時からの秒数が32ビットからあふれ、NTPに問題が起こる。
Unixなど。1970年1月1日0時(Unix epoch)からの秒数が31ビットからあふれ、32ビット符号付きで処理しているシステムに問題が起こる。
GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から3072週後にあふれて0に戻る。(10ビットでは3回目)
HFSのタイムスタンプは2040年2月6日までしか取り扱えない。
System zのSTCK命令で取得する64ビットのTODクロックは2042年9月17日中にオーバーフローする。
2038年問題の1980年起点版。FATファイルシステムのタイムスタンプなどが1980年起点である。
1950年 - 2049年を下2桁で表現しているシステムに問題が起こる。同様のものに2030年問題や2070年問題などがある。
1970年 - 2069年を下2桁で表現しているシステムに問題が起こる。同様のものに2030年問題や2050年問題などがある。
FATファイルシステムのタイムスタンプの起点の1980年1月1日を基点として、年数を下2桁だけで処理するソフトウェアなどは、その起点の99年後(2079年12月31日)までしか正常動作しない。
2000年以降に作られた年数を2桁で表すシステムや、2100年を閏年と誤解したシステムに問題が起こる。
FATファイルシステムのタイムスタンプは2107年12月31日までしか取り扱えない。
更新されたGPSは内部処理で週数を13ビットで管理しており、この頃にあふれて0に戻る(正確な日時は未定)。
2286年問題-2286年11月20日17時46分40秒に起こる。原因は、2001年問題と同じ。
Visual C++において、3000年1月1日以降の日付処理に不具合が生じる。
