年を2桁で処理するシステムの「2020年問題」 109
ストーリー by hylom
プログラムは意外に長く使われる 部門より
プログラムは意外に長く使われる 部門より
過去に開発されたシステムでは、年を西暦の下2桁でのみ処理するものが存在するそうだ。そういったシステムの一部では2000年以降も適切に処理を行うために下2桁が「00〜19」の場合は「2000年〜2019年」として扱い、そうでない場合は「19XX年」として扱うという処理になっているものがあり、2020年を迎えた現在そういったシステムが問題となっているという(New Scientist、GIGAZINE)。
「00〜20」という範囲が選択された理由については、UNIX時刻では1970年を時刻の基準点としており、そこからプラスマイナス50年の範囲ということで1920年から2019年という設定にしたとされている。こういったシステムでは2020年という年を適切に処理できないケースがあり、複数のシステムやプログラムでこれに関連する問題が確認されているそうだ。
なお、これとはまったく関係はないが、例えば「年4桁+月2桁」の数字6桁で年月を表現するルールを採用している場合、2020年を迎えた現在それが「年2桁+月2桁+日2桁」との表記との区別がつかないという問題も指摘されている。例えば2008年4月のデータを「200804hogehoge.txt」のようなファイルに保存していた場合、ルールを知らない人がこれを見たら「2020年8月4日のデータ」のように解釈してしまう恐れがある。
なぜ年月日ではないのか (スコア:2)
>なお、これとはまったく関係はないが、例えば「年4桁+月2桁」の数字6桁で年月を表現するルールを採用している場合、2020年を迎えた現在それが「年2桁+月2桁+日2桁」との表記との区別がつかないという問題も指摘されている。
全く関係ないけどさ、日本の場合は年・月・日の順序は変わらないけど
英語圏では
MM/DD/YY 01/14/20
DD/MM/YY 14/01/20
って二種類の表記があるけどコレって混同しないのかな?
そもそもの問題として一番頻繁に数字が変わるケタを右側に持ってこない理由がいまいちわからない。なんで年を最後に宣言するんだ?
Re:なぜ年月日ではないのか (スコア:1)
>DD/MM/YY 14/01/20
>
>って二種類の表記があるけどコレって混同しないのかな?
エンディアンですね
>そもそもの問題として一番頻繁に数字が変わるケタを右側に持ってこない理由がいまいちわからない。
やっぱりエンディアンですね
#本来、MMの部分は数字を使わなかったんでしょうね(Jan,Febとか)
Re: (スコア:0)
省略すれば現在の月/年と考えれば合理的ではある。
DD書いてる途中で敵が攻めてきたらやばいじゃん。年なんてめったに変わらないものは後回しさ!
Re: (スコア:0)
敵が攻めて来て居るのなら日付確認以前に対処しろや。
これとはまったく関係はない (スコア:0, フレームのもと)
タレコミ文の末尾で「なお、これとはまったく関係はないが」とわざわざ但し書きをつけて関係ない話を始めるから
全く関係ないコメントが出てきてしまう。まさに蛇足。
そもそも「数字6桁で年月を表現するルールを採用」してるんだからそのルールに従って読めばいい。
ルールを知らない人は年月日の読み方がわからなくなる?そんなの当たり前。
略記法なんだから、情報を落として文字数が少なくなるようにしてるんだから、曖昧さが出て当然。
> なんで年を最後に宣言するんだ?
英語はその順番で書くから。以上
Re: (スコア:0)
アメリカ:MMDDYYYY
イギリス:DDMMYYYY
カナダ:YYYYMMDD
英語だからこの順番なんて決まりはねぇよw
Re: (スコア:0)
NATO方式に統一しろ (YYYYMMDD)
ヤードポンド法は滅ぼすべき
Re: (スコア:0)
いや、ISO (YYYY-MM-DD)かな。
Re: (スコア:0)
Re: (スコア:0)
moon
Re: (スコア:0)
うさぎ
Re: (スコア:0)
むつき
Re: (スコア:0)
それだけだとYY/MM/DDとDD/MM/YYを区別できないのでは?
Re: (スコア:0)
紛らわしいから、Jan、Febとか月の英単語短縮になってるのはよく見る。特に国際的に展開してるとこ。
たぶん、国内向けオンリーの場合はその国の表記でやってるんじゃね。
最後の行については、
そもそも言いたいことを先に持ってこい(Subject・Verb・Object)な文化だし、合理的といえば合理的かも。
日本語みたいに、主語から修飾語や目的語がダラダラ続いて最後に肝心の動詞がある方がマイナーな気が。
住所も日本とは反対でしょ。番地から国へ(小から大)。
まぁこれに関しては、日本の大きいところから狭めていく方がわかりやすい。
途中でも場所が想像できるけど、番地やストリートから言われても「どこのだよ」って。
同じ英語なのに、米英で細かい違いが多いのが面倒。
この日付のように、致命的な誤解を生む違いもあるし。
Re:なぜ年月日ではないのか (スコア:1)
MS の DOTNET Framework では日本のロケールでは月の短縮名は「1月,2月」とか「睦月,如月」とかではなく、「Jan,Feb」なのよね。
で英語にも対応ってことでやってたらロシアで動かないとクレームが来たことがある。
マクロの基本は検索置換(by y.mikome)
Re: (スコア:0)
全く関係ないけど、ドイツ語の分離動詞を習ったとき、最後まで読まないと
分からないから日本語は難しいとか嘘やんと思った。
Re: (スコア:0)
全く関係ないけど、日本語はその場の空気も読まないといけませんからね・・・
Re: (スコア:0)
全く関係ないのに、いちいち日本語をディスっていく人って……
空気を読まなくてもいい言語なんて存在するの?
Re: (スコア:0)
#3744863ですけど、別に日本語を否定したり軽蔑しているわけではありませんよ。
まあ、確かに「空気を読まないといけない」と言うのは不適切でしたね。
今海外にいるんですけど、こちらの人はYes、Noをはっきり言いますから、それに比べて日本人と話すと言葉を言葉通りに受けてはいけない時もあり、日本語は難しいなと感じる事がありましたので、そういった事を表現したかっただけです。あと、文頭の「全く関係ないけど」もいりませんでしたね。
# まあ、何を言っても言い訳でしかないですし、私の言葉の拙さが招いた結果ですから、何を言われてもしょうがないですけど・・・
Re:なぜ年月日ではないのか (スコア:1)
> 今海外にいるんですけど、こちらの人はYes、Noをはっきり言いますから
まあ、東海岸のロイヤーは「Yes、Noをはっきり」言わずに、
京都人なみの婉曲表現を駆使すると聞いたことあるので、
海外でもいろいろなんじゃないですかね。
特に狭いコミュニティーほどハイコンテキストなコミュニケーションが
求められる、というのはありそうですが。
Re: (スコア:0)
年月日の順番はフリーダムなのに、時分秒の順番が時分秒以外のケースって見ないなぁ
Re: (スコア:0)
RFC3339 [biglobe.ne.jp]に準拠するなら年月日順、年は4桁。区切りはハイフン。
「YYYY-MM-DD」であって「YYYY/MM/DD」ではない。なんでスラッシュを使うんだ?
Re: (スコア:0)
慣習ってやつじゃなかろうか。
曜日についても、週の最初は月曜って規定されてるけど、
日本だと日曜始まりのカレンダーの方がよく目にする。
Re: (スコア:0)
なんでスラッシュを使うんだ?
日本人の一部で、ハイフンは期間を表現するために予約されているからです。
Re: (スコア:0)
小数点が.か,かみたいな物でその辺も国によってちがうんだよ。
カナダはYYYY-MM-DDだけど、日本はYYYY/MM/DD、米国はMM/DD/YYYYみたいに。
Re: (スコア:0)
国際単位系「"."も","もどちらも小数点で、桁区切りは空白だぞ」
Java/Perl/Ruby「数値の桁区切りに"_"を使えるようにしたぞ」
C++/電卓「桁は'で区切るぞ」
Re: (スコア:0)
「YYYY.MM.DD」ってピリオド区切りにする文化も(一部では?)ありますし。
そして次の20年が始まる (スコア:1)
Re: (スコア:0)
「誰だよ、こんな中途半端な修正したのは!」(俺やん……)
Re: (スコア:0)
2040年到来前にそのアドホックな対応をしたシステムは2038年問題で滅びるのではないか
関連で2030年問題は誰も書かないの? (スコア:1)
今回の事例とほぼ同じ現象が、ほぼすべてのWindowsのデフォルト設定で、30年=1930年が起きます。
ExcelやAccess等も同様の挙動をします。
Excelのヘルプにありますが、Windowsの設定変更で2桁から4桁変更時の挙動が変わります。 [office.com]
2030年まであと10年を切ったのでそろそろ実務でも問題になるんじゃないかな。
ちなみにWin95のWin2k対応辺りからから29=2029年,30=1930年でやってきてたと思うので、20年近い遺産なんですかね。
# 微妙に閾値変わってた気がするんだけど……
昭和が終わった時に (スコア:0)
昭和が終わるときに、あれだけ話題になって
2000年問題でも騒がれて
まだ、そのままなのはなんでなんでしょうね
某宅配便会社は、2000年問題の時に、データベースは昭和二桁(加算中)なんで大丈夫とか言ってましたが、昭和100年問題も来るのかな?
Re: (スコア:0)
必要な人員や予算が確保できなきゃ、出来る範囲で対応するしかなかろう。
Re: (スコア:0)
古くなればなるほど弄れなくなるもんです
プラスマイナス50年の範囲 (スコア:0)
> 「00〜20」という範囲が選択された理由については、UNIX時刻では1970年を時刻の基準点としており、
> そこからプラスマイナス50年の範囲ということで1920年から2019年という設定にしたとされている
こんなこと考えて範囲設定してる人は本当にいる(いた)のかな。ものすごくいなさそうなんだけど・・・
なんとなく2020年にしちゃった感じでしょ。
#2020って遥か未来に感じる
Re:プラスマイナス50年の範囲 (スコア:1)
2000年問題に直面したシステムはだいたいメインフレームかオフコン上のものなんじゃないの?
あの世界にUNIXTIMEなんて存在しないから1970年を念頭に置くわけがない。
SORTのALTSEQで指定する数をなるべく少なく済む方向で考えてたまたま2020年までになったと言うのならわかる。
私の勤務先では2009年までで十分だったから2008年頃に全JCL点検して元に戻した。
Re: (スコア:0)
> #2020って遥か未来に感じる
ブレードランナーの一年後ですからね。
身の回りの放射性物質が増えたことぐらいしか実現してない。
Re:プラスマイナス50年の範囲 (スコア:2)
デロリアンが行った未来は2015年だったとか.....
知人のデロリアンオーナーが、数年間ネタにしていました
------------
惑星ケイロンまであと何マイル?
Re: (スコア:0)
1995年には2015年に汎用人型決戦兵器が未知の存在と戦うはずだったので……
Re: (スコア:0)
3月までにブレイブポリス発足しますからね。
クオリディアとかゆゆゆとか、最近のフィクションでも話のキッカケが起きた年になってたりするのは
作中の時期をそんなに先にしたくないからだろうか。
Re:プラスマイナス50年の範囲 (スコア:2)
それを考えるとドラえもんの製造年を2112年にしたのは正解ですね。
まだ92年もある。
脳味噌腐乱中…
Re: (スコア:0)
昔は21世紀(2012年?)から来たことになっていたが、実際に21世紀になってしまったので22世紀に伸ばし、セワシも孫の設定だったのが孫の孫に変更されたと聞いたのだが、どうなんだろうか?
Re:プラスマイナス50年の範囲 (スコア:1)
ドラえもん0巻の1970年資料でも系統図がひ孫の子になってますよ
Re: (スコア:0)
調べたら三秒で分かるようなことも調べられないのか...
Re: (スコア:0)
タイムマシンはもうとっくにできていることになっているけどね。
秘密裡にCERNとかで運用されてるのかもしれないけど。
Re: (スコア:0)
ここまででAKIRAが出てないとはどういうことだ!
Re: (スコア:0)
2000年問題と同じで、ここまで長期間使い続けるとは思ってなかったんだろうな。
今だって20年後まで考慮してシステム設計する人がどれだけいることか。
Re: (スコア:0)
> 今だって20年後まで考慮してシステム設計する人がどれだけいることか。
これは、システム設計している人の考えが及ばないために、そのような
システム設計になるのではなく、金を出す人の考えが浅いために
起こっている場合がほとんどだと思う。
Re:プラスマイナス50年の範囲 (スコア:2)
20年ってOSの保守期間超えてるのに?
10年もすればOSやミドルウェアやソフトウェアのEOLが確実に来るのに、それを超えて同じまま使い続けるなんて発想で設計する若い人がいるとは思えないんだけど。
Re: (スコア:0)
ウルトラQの「2020年の挑戦」は実は西暦2020年とは明言されていないんだよな。
ヤングチャンピオン版ウルトラ怪獣擬人化計画では西暦2020年という解釈になってたけど。
#ウルトラQのコミックが(放送当時ではなく)発売された時、ふと価格を見たら
#本体2020円で大笑いした記憶があるな。蛇足。