アカウント名:
パスワード:
決まってから、実装すればいいのに。
まぁ第一、新元号の発表が遅すぎるが。来年に入ってからとか、何考えてんだ!めっちゃ混乱を招くだけな気がする。
後藤隊長が「だから!遅すぎたと言ってるんだ!」と叫んだシーンが脳内でリピート再生されてる。
全く同感だな。だからMSの対応が普通。日本政府が信じられないほど糞バカ過ぎんのよ。
あいつら目で見て分かる物しか理解できないとか、真顔で言うからな。このくらいやれば、政府のバカどもでも影響範囲の大きさが目で見て分かるんじゃね。バカは死ななきゃ治らないけど、この程度の荒療治ですめば御の字だ。
一方、平成になる時の新元号の発表は改元の前日だった
#混乱したかどうかは覚えてない
そもそも平成への改元は昭和天皇の崩御に伴うものなので、新元号の発表翌日の改元は当然です。それに、前回はここまでコンピュータ社会になっていなかったので、新元号への訂正印で済んだ書類も多々ありました。
#当時は若かったので、システム的な影響がどれだけあったかは知らない。
「昭和95年」を入力されてエラーにならず西暦に変換できるような処理系ならば入力については問題ない。後に、バージョンアップで、平成暦の入出力ができるように変更したと、定年間近の上司に自慢された。まあ、「平成32年」とかではなくて、下手に元号を「??」なんかにされて、中途半端な変なデータが紛れ込む方がたちが悪い。
「新元号が追加されることに伴う問題をより早い段階で発見し、来る 2019 年 5 月に問題が発生することを未然に防ぐことを目的に」とか、馬鹿じゃないのかと思います。そんなん、テスト必要なアプリはとっくにレジストリへ手動追加してテストしてますがな。
それより、未来の日付で印刷物を作成するようなケースで「??1年」とか出ちゃうのが困る。「平成31年」で問題ないものも多いだろうに。
# これ、手動削除もできないんじゃないの?
なるほど平成の次の最後の元号が???と伝わってるのはこのためでしたか
長期政権なのに長期的課題に対応できずに滅んだ国として未来でも有名ですので気になりました
新元号問題、昭和100年問題、2036年問題(NTP)、2038年問題(32bitUNIXタイムスタンプ)、2079年問題(FATタイムスタンプ)・・・まだ何か残っていたかな?
旧暦2033年問題について [nao.ac.jp]という厄介事もあるというかないというか…
定気法を導入したのがそもそも諸悪の根源。冬至だけを基準に平気法を維持すべきだった。
年問題https://ja.wikipedia.org/wiki/%E5%B9%B4%E5%95%8F%E9%A1%8C [wikipedia.org]
まだ何か残っていたかな?
閏年を正しく扱えない技術者問題ェ
2100 年問題。コンピュータが普及してから初めての 4 で割り切れる閏年でない年です。(2000 年は 400 で割り切れたので閏年でしたね)
今の人「その頃には今の処理なんか基盤変わってて使え無くなってるだろ?」そして2100年。。。未来人「なんでこんな作りにしてんだよ!」#歴史は繰り返す
カエサル「閏年は4年に1回で十分だろう。400年に3日しか狂わないし」グレゴリウス13世「あいつの糞仕様を1600年以上も放置しやがって。もう10日も狂ってるじゃないか」
なもの積算秒で入れておいて、表示するときに西暦や和暦にレンダリングすればいいのに。
??なら日本語が読めない開発者でも(日本語フォントさえインストールしてあれば)異常が一目で分かる、というメリットがあるね。
しかし、漢字二文字になるというのはもう決定事項なのかな。
# 今年は神護景雲1252年
元号選定手続について [archives.go.jp]
2(2)イ 漢字2字であること。
そこで、utf-8で6バイトに収まらない漢字を選ぶ罠
#絵文字とか
「圭」とか「申」とか「十」とか混ざったりして
>「圭」とか「申」とか「十」とか混ざったりして某氏の問題は宮内庁のウェブ担当者がNGを出した……?
その二文字が全部、上下なり左右なりに分かれる漢字になるのかも。
走召元年が楽しみです
??なら日本語が読めない開発者でも
example.com/?gengou=??
yes we can
それも良いですが次の改元の時に同じのになるからなぁもう即位の時点で次まで決めちゃえば良いんじゃないですかね
つまり「元の元号の2文字目をとり、頭に不をつける」ということで大正→不正明治→不治昭和→不和平成→不成という仮元号を……
マリオのハテナブロックじゃないのか
#好きな数字を入れてください
元号を扱うシステムはだいたいもう改元も西暦変換もできてることが多いからいいよ。
それより頭文字KMTSHの再利用とか、3文字以上とかさえやめてくれれば。
文句言っている人が多いけど、何に文句言ってるのかわからん。いずれは切り替えが必要だし、実データで新元号が現れる直前になって修正されるより、事前にやってもらった方がよいだろ。
元は政府の方針がクソなんだし、どうやっても対応の必要性はゼロにはならん。「5分遅れの時計と止まっている時計のどっちが正確か」みたいな話で、「平成31年5月」と「??1年5月」のどっちがよいのかなんて決めようがない。日付変換時には「平成31年5月」が通るように修正するといってるんだから、十分な対応だろう。
「日付データを和暦で持つプログラムが困る」とかいう人がいるけど、そんなプログラム、そもそもレジストリ見たり.NETのインフラ使ったりしてないから影響ないでしょ。
福祉系のシステムなどでは未来の日付を扱うことがよくあります。 例えば,ある人が18歳になる年とか,後期高齢者になる年とか。 現状では「平成100年」なんて表示されるときもありますが,これは問題無いです。
しかし,この「??」が導入されると「??70年」などという阿呆な表示になってしまいます。 証書関係では有効期限を印刷しているものがありますが,これも「平成31年4月1日〜??2年3月31日」なんて印刷されてしまいます。
データの保持が問題なのではなく,それを印刷物などで使う場面で問題が生じるのです。
5分遅れの時計は5分加算することにより正しい時刻を算出できるのに対し、止まっている時計は正しい時刻について何の情報も与えてくれない、という意味では5分遅れの時計がより正確と言えるが、5分遅れの時計は永遠に正しい時刻を示すことはないのに対し、止まっている時計は12時間に1回正しい時刻を示す。
「物事の評価は捉え方による」というたとえで使ったんじゃないかと。
# 止まっている時計の実時刻との差は、-6~+6時間。時刻差の絶対値を平均すると3時間。# 「5分遅れ」だと「そりゃ5分遅れの方が正確だろう」と思うが、「4時間遅れの時計」だとどうなんだろうね。
または、いつものように無視されたか。
これって、5月からは、2019年の五月以降の日付を Windows10 で指定する場合、「??年6月1日」って設定しなければいけない。ってことなのだよ。Excel で「平成31年」とか打ったらエラーにされる。ってことだ。
しかもテスター向けではなく、一般のユーザーに対して強制アップデートでだ。
日本支社側に止める人、いなかったか。
政府に文句言おうよ。上流がトロいせいで下流にしわ寄せが来てるって事例なんだから。
過去、千数年以上にわたってみても「改元の予告」が一年以上前にあった事例なんてないのに何言ってんだ。
んなこと言ったら、天皇が「形の上の主権」ですらなくなったのは昭和の途中からだし、ITシステムが改元の影響を受けたのは平成がはじまりだ。時代や技術の変化を無視して、過去に前例がないからとか言っちゃう進歩のないやつがネットなんか使ってるんじゃねーよ。木簡の裏にでも書いてろ。
それが分かっているならレジストリの項目を、サクッと削除しておけばよい。面倒ではあるけれども。
データベース等恒久保存データには常に西暦なりUnix時刻なりでいれて表示時に一過性で変換しろってことだよ言わせんな
64ビットで持っておけば問題無いのでは。
>生年月日をUnix Timeで保持って誰でも新人の頃に一度はする設計ミスだよね
若い人はわからないかもしれないがな、1970年1月1日よりも前に生まれた人ってのはまだたくさんいるんじゃよ…………
………
え、ちょ、マジで「1970年より前に生まれたなんて都市伝説だよね、符号なしUNIX Timeが定義できないじゃんウケルありえなーい」なんて思ってないよね?
signed 64bitで持っておけば問題無いのでは
>signed 64bitで持っておけば問題無いのでは
うんうん。「昭和100年問題」に対して、「年号の変数の幅を±64ビットでもって設計すればいいじゃんいいじゃん」ってご意見ですねw貴重なご意見ありがとうございますw
だ れ が そ の 潤 沢 な メ モ リ を 買 っ て く れ る ん じ ゃ い
今時の64ビットでsignedな環境なら、別に問題ないでしょ。
$ date -d @-31536000 => Wed Jan 1 09:00:00 JST 1969
いくら新人でも設計してるときに「いや無駄でしょこれwww」って気づくわボケ
昭和の時代から生き残っているシステム相手にそんなこと言っても無駄だよ。
世の中にはEDIのデータでもって取引先に昭和年を強制する会社があってですね
平成32年を西暦に変換する処理があったとしたら、今回の更新でエラーになっちゃうんだよな。地味に致命的かも知れない…。
レジストリ消せば良いとか気軽に言ってくれるよまったく。テストする側がレジストリ追加して試験すりゃ良いだけで、全ユーザーに中途半端な設定をばらまく必要は無いだろうに。
日記に書いてくれると助かります。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
さすがに、これはちょっと… (スコア:5, すばらしい洞察)
決まってから、実装すればいいのに。
まぁ第一、新元号の発表が遅すぎるが。
来年に入ってからとか、何考えてんだ!
めっちゃ混乱を招くだけな気がする。
Re:さすがに、これはちょっと… (スコア:1)
後藤隊長が「だから!遅すぎたと言ってるんだ!」と叫んだシーンが脳内でリピート再生されてる。
Re:さすがに、これはちょっと… (スコア:2, すばらしい洞察)
全く同感だな。
だからMSの対応が普通。日本政府が信じられないほど糞バカ過ぎんのよ。
あいつら目で見て分かる物しか理解できないとか、真顔で言うからな。
このくらいやれば、政府のバカどもでも影響範囲の大きさが目で見て分かるんじゃね。
バカは死ななきゃ治らないけど、この程度の荒療治ですめば御の字だ。
Re: (スコア:0)
一方、平成になる時の新元号の発表は改元の前日だった
#混乱したかどうかは覚えてない
昔も影響はそれなりにあった (スコア:2)
Re:さすがに、これはちょっと… (スコア:1)
そもそも平成への改元は昭和天皇の崩御に伴うものなので、新元号の発表翌日の改元は当然です。
それに、前回はここまでコンピュータ社会になっていなかったので、新元号への訂正印で済んだ書類も多々ありました。
#当時は若かったので、システム的な影響がどれだけあったかは知らない。
Re: (スコア:0)
信号機は車が交差点から3m以内に近づくまで、どれも不点灯とする
みたいな話だよね
Re: (スコア:0)
「昭和95年」を入力されてエラーにならず西暦に変換できるような処理系ならば入力については問題ない。
後に、バージョンアップで、平成暦の入出力ができるように変更したと、定年間近の上司に自慢された。
まあ、「平成32年」とかではなくて、下手に元号を「??」なんかにされて、中途半端な変なデータが紛れ込む方がたちが悪い。
Re: (スコア:0)
「新元号が追加されることに伴う問題をより早い段階で発見し、来る 2019 年 5 月に問題が発生することを未然に防ぐことを目的に」とか、馬鹿じゃないのかと思います。
そんなん、テスト必要なアプリはとっくにレジストリへ手動追加してテストしてますがな。
それより、未来の日付で印刷物を作成するようなケースで「??1年」とか出ちゃうのが困る。
「平成31年」で問題ないものも多いだろうに。
# これ、手動削除もできないんじゃないの?
未来から来ました (スコア:2)
なるほど平成の次の最後の元号が???と伝わってるのはこのためでしたか
長期政権なのに長期的課題に対応できずに滅んだ国として未来でも有名ですので
気になりました
暦問題 (スコア:1)
新元号問題、昭和100年問題、2036年問題(NTP)、2038年問題(32bitUNIXタイムスタンプ)、2079年問題(FATタイムスタンプ)・・・まだ何か残っていたかな?
Re:暦問題 (スコア:1)
旧暦2033年問題について [nao.ac.jp]
という厄介事もあるというかないというか…
Re:暦問題 (スコア:1)
定気法を導入したのがそもそも諸悪の根源。冬至だけを基準に平気法を維持すべきだった。
Re:暦問題 (スコア:1)
年問題
https://ja.wikipedia.org/wiki/%E5%B9%B4%E5%95%8F%E9%A1%8C [wikipedia.org]
Re: (スコア:0)
まだ何か残っていたかな?
閏年を正しく扱えない技術者問題ェ
Re: (スコア:0)
2100 年問題。
コンピュータが普及してから初めての 4 で割り切れる閏年でない年です。
(2000 年は 400 で割り切れたので閏年でしたね)
Re:暦問題 (スコア:1)
今の人「その頃には今の処理なんか基盤変わってて使え無くなってるだろ?」
そして2100年。。。
未来人「なんでこんな作りにしてんだよ!」
#歴史は繰り返す
Re:暦問題 (スコア:1)
カエサル「閏年は4年に1回で十分だろう。400年に3日しか狂わないし」
グレゴリウス13世「あいつの糞仕様を1600年以上も放置しやがって。もう10日も狂ってるじゃないか」
元号を文字列にレンダリングして格納するシステムがタコじゃね (スコア:1)
なもの積算秒で入れておいて、表示するときに西暦や和暦にレンダリングすればいいのに。
「未定」とかの方がよくないか?と思ったけど (スコア:0)
??なら日本語が読めない開発者でも(日本語フォントさえインストールしてあれば)異常が一目で分かる、というメリットがあるね。
しかし、漢字二文字になるというのはもう決定事項なのかな。
# 今年は神護景雲1252年
Re:「未定」とかの方がよくないか?と思ったけど (スコア:3, 参考になる)
元号選定手続について [archives.go.jp]
2(2)
イ 漢字2字であること。
Re: (スコア:0)
そこで、utf-8で6バイトに収まらない漢字を選ぶ罠
#絵文字とか
Re:「未定」とかの方がよくないか?と思ったけど (スコア:1)
「圭」とか「申」とか「十」とか混ざったりして
Re:「未定」とかの方がよくないか?と思ったけど (スコア:1)
>「圭」とか「申」とか「十」とか混ざったりして
某氏の問題は宮内庁のウェブ担当者がNGを出した……?
-- う~ん、バッドノウハウ?
Re: (スコア:0)
その二文字が全部、上下なり左右なりに分かれる漢字になるのかも。
Re: (スコア:0)
走召元年が楽しみです
Re: (スコア:0)
??なら日本語が読めない開発者でも
example.com/?gengou=??
yes we can
Re:「未定」とかの方がよくないか?と思ったけど (スコア:2)
それも良いですが次の改元の時に同じのになるからなぁ
もう即位の時点で次まで決めちゃえば良いんじゃないですかね
Re:「未定」とかの方がよくないか?と思ったけど (スコア:1)
つまり「元の元号の2文字目をとり、頭に不をつける」ということで
大正→不正
明治→不治
昭和→不和
平成→不成
という仮元号を……
[?][?]年 (スコア:0)
マリオのハテナブロックじゃないのか
#好きな数字を入れてください
激動の昭和を乗り切ったんだ (スコア:0)
元号を扱うシステムはだいたいもう改元も西暦変換もできてることが多いからいいよ。
それより頭文字KMTSHの再利用とか、3文字以上とかさえやめてくれれば。
いずれは切り替え必要だろ (スコア:0)
文句言っている人が多いけど、何に文句言ってるのかわからん。
いずれは切り替えが必要だし、実データで新元号が現れる直前になって修正されるより、事前にやってもらった方がよいだろ。
元は政府の方針がクソなんだし、どうやっても対応の必要性はゼロにはならん。
「5分遅れの時計と止まっている時計のどっちが正確か」みたいな話で、
「平成31年5月」と「??1年5月」のどっちがよいのかなんて決めようがない。
日付変換時には「平成31年5月」が通るように修正するといってるんだから、十分な対応だろう。
「日付データを和暦で持つプログラムが困る」とかいう人がいるけど、そんなプログラム、
そもそもレジストリ見たり.NETのインフラ使ったりしてないから影響ないでしょ。
Re: (スコア:0)
福祉系のシステムなどでは未来の日付を扱うことがよくあります。 例えば,ある人が18歳になる年とか,後期高齢者になる年とか。 現状では「平成100年」なんて表示されるときもありますが,これは問題無いです。
しかし,この「??」が導入されると「??70年」などという阿呆な表示になってしまいます。 証書関係では有効期限を印刷しているものがありますが,これも「平成31年4月1日〜??2年3月31日」なんて印刷されてしまいます。
データの保持が問題なのではなく,それを印刷物などで使う場面で問題が生じるのです。
Re:いずれは切り替え必要だろ (スコア:1)
5分遅れの時計は5分加算することにより正しい時刻を算出できるのに対し、止まっている時計は正しい時刻について何の情報も与えてくれない、という意味では5分遅れの時計がより正確と言えるが、
5分遅れの時計は永遠に正しい時刻を示すことはないのに対し、止まっている時計は12時間に1回正しい時刻を示す。
「物事の評価は捉え方による」というたとえで使ったんじゃないかと。
# 止まっている時計の実時刻との差は、-6~+6時間。時刻差の絶対値を平均すると3時間。
# 「5分遅れ」だと「そりゃ5分遅れの方が正確だろう」と思うが、「4時間遅れの時計」だとどうなんだろうね。
和暦を有効にしたテスターはいなかったのか (スコア:0)
または、いつものように無視されたか。
これって、5月からは、2019年の五月以降の日付を Windows10 で指定する場合、「??年6月1日」って設定しなければいけない。
ってことなのだよ。
Excel で「平成31年」とか打ったらエラーにされる。ってことだ。
しかもテスター向けではなく、一般のユーザーに対して強制アップデートでだ。
日本支社側に止める人、いなかったか。
Re: (スコア:0)
政府に文句言おうよ。
上流がトロいせいで下流にしわ寄せが来てるって事例なんだから。
Re: (スコア:0)
過去、千数年以上にわたってみても「改元の予告」が一年以上前にあった事例なんてないのに何言ってんだ。
んなこと言ったら、天皇が「形の上の主権」ですらなくなったのは昭和の途中からだし、ITシステムが改元の影響を受けたのは平成がはじまりだ。
時代や技術の変化を無視して、過去に前例がないからとか言っちゃう進歩のないやつがネットなんか使ってるんじゃねーよ。木簡の裏にでも書いてろ。
Re: (スコア:0)
それが分かっているならレジストリの項目を、サクッと削除しておけばよい。面倒ではあるけれども。
Re: (スコア:0)
データベース等恒久保存データには常に西暦なりUnix時刻なりでいれて表示時に一過性で変換しろってことだよ言わせんな
Re: (スコア:0)
Re: (スコア:0)
64ビットで持っておけば問題無いのでは。
Re: (スコア:0)
>生年月日をUnix Timeで保持って誰でも新人の頃に一度はする設計ミスだよね
64ビットで持っておけば問題無いのでは。
若い人はわからないかもしれないがな、1970年1月1日よりも前に生まれた人ってのはまだたくさんいるんじゃよ…………
………
………
え、ちょ、マジで「1970年より前に生まれたなんて都市伝説だよね、符号なしUNIX Timeが定義できないじゃんウケルありえなーい」なんて思ってないよね?
Re: (スコア:0)
signed 64bitで持っておけば問題無いのでは
Re: (スコア:0)
>signed 64bitで持っておけば問題無いのでは
うんうん。「昭和100年問題」に対して、「年号の変数の幅を±64ビットでもって設計すればいいじゃんいいじゃん」ってご意見ですねw
貴重なご意見ありがとうございますw
だ れ が そ の 潤 沢 な メ モ リ を 買 っ て く れ る ん じ ゃ い
Re: (スコア:0)
今時の64ビットでsignedな環境なら、別に問題ないでしょ。
$ date -d @-31536000 => Wed Jan 1 09:00:00 JST 1969
Re: (スコア:0)
いくら新人でも設計してるときに「いや無駄でしょこれwww」って気づくわボケ
Re: (スコア:0)
昭和の時代から生き残っているシステム相手にそんなこと言っても無駄だよ。
Re: (スコア:0)
世の中にはEDIのデータでもって取引先に昭和年を強制する会社があってですね
Re: (スコア:0, 興味深い)
平成32年を西暦に変換する処理があったとしたら、今回の更新でエラーになっちゃうんだよな。
地味に致命的かも知れない…。
レジストリ消せば良いとか気軽に言ってくれるよまったく。
テストする側がレジストリ追加して試験すりゃ良いだけで、全ユーザーに中途半端な設定をばらまく必要は無いだろうに。
Re: (スコア:0)
日記に書いてくれると助かります。