アカウント名:
パスワード:
文句言っている人が多いけど、何に文句言ってるのかわからん。いずれは切り替えが必要だし、実データで新元号が現れる直前になって修正されるより、事前にやってもらった方がよいだろ。
元は政府の方針がクソなんだし、どうやっても対応の必要性はゼロにはならん。「5分遅れの時計と止まっている時計のどっちが正確か」みたいな話で、「平成31年5月」と「??1年5月」のどっちがよいのかなんて決めようがない。日付変換時には「平成31年5月」が通るように修正するといってるんだから、十分な対応だろう。
「日付データを和暦で持つプログラムが困る」とかいう人がいるけど、そんなプログラム、そもそもレジストリ見たり.NETのインフラ使ったりしてないから影響ないでしょ。
福祉系のシステムなどでは未来の日付を扱うことがよくあります。 例えば,ある人が18歳になる年とか,後期高齢者になる年とか。 現状では「平成100年」なんて表示されるときもありますが,これは問題無いです。
しかし,この「??」が導入されると「??70年」などという阿呆な表示になってしまいます。 証書関係では有効期限を印刷しているものがありますが,これも「平成31年4月1日〜??2年3月31日」なんて印刷されてしまいます。
データの保持が問題なのではなく,それを印刷物などで使う場面で問題が生じるのです。
存在しない平成40年とかの印刷物は問題にならんのですかね
なりません。このまま時が経過すればいずれは到達するであろう時点を,現在の表示ルールで表現したものですから。
自動車運転免許証とか持っていませんか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
いずれは切り替え必要だろ (スコア:0)
文句言っている人が多いけど、何に文句言ってるのかわからん。
いずれは切り替えが必要だし、実データで新元号が現れる直前になって修正されるより、事前にやってもらった方がよいだろ。
元は政府の方針がクソなんだし、どうやっても対応の必要性はゼロにはならん。
「5分遅れの時計と止まっている時計のどっちが正確か」みたいな話で、
「平成31年5月」と「??1年5月」のどっちがよいのかなんて決めようがない。
日付変換時には「平成31年5月」が通るように修正するといってるんだから、十分な対応だろう。
「日付データを和暦で持つプログラムが困る」とかいう人がいるけど、そんなプログラム、
そもそもレジストリ見たり.NETのインフラ使ったりしてないから影響ないでしょ。
Re: (スコア:0)
福祉系のシステムなどでは未来の日付を扱うことがよくあります。 例えば,ある人が18歳になる年とか,後期高齢者になる年とか。 現状では「平成100年」なんて表示されるときもありますが,これは問題無いです。
しかし,この「??」が導入されると「??70年」などという阿呆な表示になってしまいます。 証書関係では有効期限を印刷しているものがありますが,これも「平成31年4月1日〜??2年3月31日」なんて印刷されてしまいます。
データの保持が問題なのではなく,それを印刷物などで使う場面で問題が生じるのです。
Re:いずれは切り替え必要だろ (スコア:0)
存在しない平成40年とかの印刷物は問題にならんのですかね
Re: (スコア:0)
なりません。このまま時が経過すればいずれは到達するであろう時点を,現在の表示ルールで表現したものですから。
自動車運転免許証とか持っていませんか。