アカウント名:
パスワード:
常に西暦4桁入力するのは非効率なので、上2桁と下2桁の入力欄を分けたうえで、上はデフォルトで19が入力済みで、通常は下だけを入力するようになっていた、と推測した。そこで習慣的に2000年を下の00の入力だけして、上を19から20に直すのを忘れてしまったと。
システム修正案としては、今年なら00、来年なら01以下……という下2桁を入力したら、自動で上が20に変更されるとかかな。寿命が延びて、116歳の運転手とかが出てくると、逆のミスが出てくることになるんだろうけど。
デフォルトどころか、上2桁は19固定で入力できないシステムだったのでは。現場の入力ミスで片付く話なら、3回も話をして直らないとは考えにくい気がします。たぶん、現場では対応できず、関係部署にたらいまわされた結果ではないでしょうかね。
1/1なら2000年にできるのを見出してその場をしのいじゃった感じでしょうか116歳よりはましだから1999.12.32を打ち込むと親切にも読み替えてくれるシステムなのでは（2/29が存在しないときのための機能で）
2000年問題はまだ終わっていない。そう2100年になるまで。というより、システム更新予算が認可されなかったので、上二桁は１９固定のままではなかろうか。
予算審議委員会「いままで問題のなかったシステムを更新するのは税金の無駄遣いです。」
2000年は「100」と入力、2016年は「116」と入力（要は「本来の年-1900」を入力）で対応可能なので修正予算下りずというシステムはこの世のどこかに存在しそう
# もちろん、オペレータへの周知が徹底できずにこの件のようなことが起きて、後で揉めると
Perlの言語仕様では、2桁年を1900年からの経過年数で表すと明言されているけどそれほど知られていなかったので、古いスクリプトでは2000年以降変な表示になるのがときたまありました
ごくたまに今でも見ます
2桁または4桁も入力できて、00～99なら1900～1999、4桁入力ならそのままって実装は結構あると思う。
JavaScriptも2桁入力は1900～1999と認識されます。下記コード（ブラウザによってはjavascipt:部分が消えますので手入力要）をアドレスバーに入れてみればわかりますがjavascript:alert(new Date(00,0,1).toString()); → 西暦1900年1月1日javascript:alert(new Date(100,0,1).toString()); → 西暦100年1月1日
ChromeとIEではこうなります。
システムの問題なら他の人間にも同様の事が起こるだろうし、再交付しても同じ3回で徐々に変更されたということは、いい加減な仕事してる奴が中間にいるということ
交付する人間にシステムの不備を報告したり改善を求める権限がないのかもね中間者かシステム担当者に言ったところで「それはお前の仕事ではない」となったり日本だと窓口の人が「住所氏名、生年月日に間違いはないですか？」と確認を求めることが多いが、今どきは免許の窓口業務も派遣やパートさんが普通にやってるので、今回の話遠い将来笑えなくなるかも
> 交付する人間にシステムの不備を報告したり改善を求める権限がないのかもねあとは、権限がないことと少しだけ似ている（けど大きく違う）こととして交付する人間のJob Descriptionに不備を指摘・報告することが入っていないのかも。
いい加減な設計であるのは確かだけれど、交付事務手続き中に（アメリカの感覚で）いい加減な仕事をしている人がいるとは思えない。むしろ、3回で修正されたのだから、仕事以上の働きをした人がいる証拠。
「3回」は手続き上必要なんだろ？お役所の訂正だもんな。
> 日付の間違い自体はそれほど珍しいことではないそれはおかしいだろ何で当たり前のようにさらっと言う。ホントに当たり前ならやっぱりアメリカの役所はテキトーだ。
こんないい加減な切り抜き＆イチャモンはじめて見た。
個人的な経験からすると、DMVが書類をなくしてなかった時点で拍手だ！＃再提出に金がいるとか言い出してもめたし。
先週のNHK「境界の輪廻」を思い出した受付の内側でなくした書類が見つかると滞納金が取れなくなるのでわざとらしく外に飛ばそうとする側と受付の内側に送り返そうとする側で妙なバトルになる話
アメリカにも仮免許ってあるんだなーってのが最初の感想
下２桁で判定するシステム、和暦と西暦が混在するシステム、ローンや保険ではすでに問題の出始めている2038年問題情報処理技術者には日時スペシャリストの資格が必要。
>ローンや保険ではすでに問題の出始めている2038年問題
実例を挙げてください。
ブラウザに入っているルート証明書の有効期限が2038年1月19日を超えるものをまだ見たことがないが対応しているんだろうか。
TO
116才の女子高生を生み出せる。未成年じゃないから犯罪じゃないもん！
＃無理です
過去の日付を扱うシステムはまだ眠っているから、これからも2000年問題は出続けるということか…
「これが最後の日付け問題とは思えない。愚かな人類がプログラムを作り続ける限り、いずれ第二第三の悲劇が繰り返されることになるのだ……。」
2060年には2000年生まれが年金もらうことができるわけでな。貰いに行ったらあんた160歳だよと言われる。
ただしその頃には繰り上げでも60歳じゃなく65歳になってたりして。
70歳になってそうな予感
しかし、交付された初回ならまだしも、3回目でこれでは。
まあ、アメリカだからな。10回越えたらさすがのアメリカでも変だと思うよ。
いいか?2000年生まれが16歳になったということは、2001年生まれが15歳2019年には18歳21世紀生まれのポルノ女優が誕生する
つまり、東京五輪土産は21世紀生まれ女優のAVになるってことだよ!!!1
Ω ΩΩ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
下2桁入力の手癖 (スコア:4, すばらしい洞察)
常に西暦4桁入力するのは非効率なので、上2桁と下2桁の入力欄を分けたうえで、上はデフォルトで19が入力済みで、通常は下だけを入力するようになっていた、と推測した。
そこで習慣的に2000年を下の00の入力だけして、上を19から20に直すのを忘れてしまったと。
システム修正案としては、今年なら00、来年なら01以下……という下2桁を入力したら、自動で上が20に変更されるとかかな。
寿命が延びて、116歳の運転手とかが出てくると、逆のミスが出てくることになるんだろうけど。
Re: (スコア:0)
デフォルトどころか、上2桁は19固定で入力できないシステムだったのでは。
現場の入力ミスで片付く話なら、3回も話をして直らないとは考えにくい気がします。
たぶん、現場では対応できず、関係部署にたらいまわされた結果ではないでしょうかね。
Re: (スコア:0)
1/1なら2000年にできるのを見出してその場をしのいじゃった感じでしょうか
116歳よりはましだから
1999.12.32を打ち込むと親切にも読み替えてくれるシステムなのでは
（2/29が存在しないときのための機能で）
Re: (スコア:0)
2000年問題はまだ終わっていない。そう2100年になるまで。
というより、システム更新予算が認可されなかったので、上二桁は１９固定のままではなかろうか。
予算審議委員会「いままで問題のなかったシステムを更新するのは税金の無駄遣いです。」
Re: (スコア:0)
2000年は「100」と入力、2016年は「116」と入力（要は「本来の年-1900」を入力）
で対応可能なので修正予算下りずというシステムはこの世のどこかに存在しそう
# もちろん、オペレータへの周知が徹底できずにこの件のようなことが起きて、後で揉めると
Re:下2桁入力の手癖 (スコア:1)
Perlの言語仕様では、2桁年を1900年からの経過年数で表すと明言されているけどそれほど知られていなかったので、
古いスクリプトでは2000年以降変な表示になるのがときたまありました
ごくたまに今でも見ます
Re: (スコア:0)
2桁または4桁も入力できて、00～99なら1900～1999、4桁入力ならそのままって実装は結構あると思う。
JavaScriptも2桁入力は1900～1999と認識されます。
下記コード（ブラウザによってはjavascipt:部分が消えますので手入力要）をアドレスバーに入れてみればわかりますが
javascript:alert(new Date(00,0,1).toString()); → 西暦1900年1月1日
javascript:alert(new Date(100,0,1).toString()); → 西暦100年1月1日
ChromeとIEではこうなります。
単に発行の仕事してる奴がいい加減なだけに見える (スコア:0)
システムの問題なら他の人間にも同様の事が起こるだろうし、再交付しても同じ
3回で徐々に変更されたということは、いい加減な仕事してる奴が中間にいるということ
Re: (スコア:0)
交付する人間にシステムの不備を報告したり改善を求める権限がないのかもね
中間者かシステム担当者に言ったところで「それはお前の仕事ではない」となったり
日本だと窓口の人が「住所氏名、生年月日に間違いはないですか？」と確認を求めることが多いが、
今どきは免許の窓口業務も派遣やパートさんが普通にやってるので、今回の話遠い将来笑えなくなるかも
Re: (スコア:0)
> 交付する人間にシステムの不備を報告したり改善を求める権限がないのかもね
あとは、権限がないことと少しだけ似ている（けど大きく違う）こととして交付する人間
のJob Descriptionに不備を指摘・報告することが入っていないのかも。
Re: (スコア:0)
いい加減な設計であるのは確かだけれど、
交付事務手続き中に（アメリカの感覚で）いい加減な仕事をしている人がいるとは思えない。
むしろ、3回で修正されたのだから、仕事以上の働きをした人がいる証拠。
Re: (スコア:0)
「3回」は手続き上必要なんだろ？
お役所の訂正だもんな。
> 日付の間違い自体はそれほど珍しいことではない
それはおかしいだろ何で当たり前のようにさらっと言う。
ホントに当たり前ならやっぱりアメリカの役所はテキトーだ。
Re: (スコア:0)
こんないい加減な切り抜き＆イチャモンはじめて見た。
DMVって・・・ (スコア:0)
個人的な経験からすると、DMVが書類をなくしてなかった時点で拍手だ！
＃再提出に金がいるとか言い出してもめたし。
Re: (スコア:0)
先週のNHK「境界の輪廻」を思い出した
受付の内側でなくした書類が見つかると滞納金が取れなくなるのでわざとらしく外に飛ばそうとする側と
受付の内側に送り返そうとする側で妙なバトルになる話
仮免 (スコア:0)
アメリカにも仮免許ってあるんだなーってのが最初の感想
2000年問題終わらず (スコア:0)
下２桁で判定するシステム、和暦と西暦が混在するシステム、ローンや保険ではすでに問題の出始めている2038年問題
情報処理技術者には日時スペシャリストの資格が必要。
Re: (スコア:0)
>ローンや保険ではすでに問題の出始めている2038年問題
実例を挙げてください。
Re: (スコア:0)
ブラウザに入っているルート証明書の有効期限が2038年1月19日を超えるものをまだ見たことがないが
対応しているんだろうか。
２年後日本でも起きそう (スコア:0)
TO
これを応用すれば (スコア:0)
116才の女子高生を生み出せる。
未成年じゃないから犯罪じゃないもん！
＃無理です
Re:この手の話はもう飽きた (スコア:1)
過去の日付を扱うシステムはまだ眠っているから、これからも2000年問題は出続けるということか…
Re: (スコア:0)
「これが最後の日付け問題とは思えない。
愚かな人類がプログラムを作り続ける限り、いずれ第二第三の悲劇が繰り返されることになるのだ……。」
日本の話しだが (スコア:0)
2060年には2000年生まれが年金もらうことができるわけでな。
貰いに行ったらあんた160歳だよと言われる。
ただしその頃には繰り上げでも60歳じゃなく65歳になってたりして。
Re: (スコア:0)
70歳になってそうな予感
Re: (スコア:0)
しかし、交付された初回ならまだしも、3回目でこれでは。
Re: (スコア:0)
まあ、アメリカだからな。
10回越えたらさすがのアメリカでも変だと思うよ。
Re: (スコア:0)
いいか?
2000年生まれが16歳になったということは、2001年生まれが15歳
2019年には18歳21世紀生まれのポルノ女優が誕生する
つまり、東京五輪土産は21世紀生まれ女優のAVになるってことだよ!!!1
Ω ΩΩ