アカウント名:
パスワード:
単純に不足桁分の0を後ろに追加してしまうだけならまだ分からんでもないのだが、(タレコミにもあるけど)先頭の1を消してしまうというのはどういう作りなんだろう？
申請書類なんかで「『1.明治 2.大正 3.昭和 4.平成』で番号に○を付けろ」みたいなのは良くあるので日付項目であればそれなりに納得いくのですが、この場合は金額(数値項目)ですからねえ。謎だ。
それまでにシステムの方に寿命がきている自信があるのでしょう。
#まんま2000年問題を彷彿とさせるけど、今システム設計する立場だったら私も自信あるな。#そーとー長く見て50年もののシステムだったとしても、それまでにその回数代替わりする状況って、多分日本が終わってる。
一世一元の詔のシステム自体が変わるという発想も必要では？
これが流石に、「何年かのうちにすごい宗教家が出てきて、BC, AD使わなくなるよ」というのなら杞憂だと思いますが、歴史的には現状のシステムの方が短いので、突拍子もないとまでは言えないですし。
>一世一元の詔のシステム自体が変わるという発想も必要では？オフトピだけど、そもそもそんな歴史も大してない方法に何拘っているのか解らん。前陛下なんて末年は体調が良くなかったので本当なら引退してしまえば良いのにと思っていたのだが。流石に思い付きで元号を替えられると困るだろうが、強制的に国民の意識を向けるのには良いと思うんだ。来年あたり、大震災からの復興の年と成る様に希望を込めてとか、どう？
> 一世一元の詔のシステム自体が変わるという発想も必要では？まったく必要ないです。
何故なら、そうなれば元ACの想定する「不敬」を気にする必要がなくなるから。（視野狭窄的回答）
何故なら、それは十分に変事なのでシステムの改修費用、期間を別途貰って対応できるから。（理想論的回答）
何故なら、中途半端に対応可能にしておくと「こんな事もあるわけですし、年月日は西暦で扱うように変更しましょう」と言ってまっとうな仕様に変更する、非常に貴重な機会を無為に失うことになるから。（逆説的回答）
毎回、性別項目の定義で設計を悩んでしまう私に良いアドバイスを
うちのシステムは １－明治、３－大正、５－昭和、７－平成 だから大丈夫さっ
空海 [wikipedia.org]は？
>【西暦を採用することは利用者に見えないところでもＮＧ】 ↓「内部データは神武皇紀で持てばいいんじゃね? 計算楽だし、法律的根拠もクリアだし」
というようなシステムが実際に存在したとかの伝説もありますね。
安田生命がそうだったらしいですね。Wikipedia にも記述があるし、探してみると、こんな記事 [itmedia.co.jp]もありました。
皇紀を採用した安田生命保険の先見の明実は安田生命は1940年を起点にプラスとマイナス99年を保持していたのです。メインフレームでいうところのパック10進数だと、1バイトで正負2桁の数字を保持できる方式で1841年から2039年まで、199年間の年の情報を持てます。1841年は伊藤博文が生まれた年で、1970年代というシステム化した年からすると十分古い年から、70年近く先まで持つ2039年まで1バイトで扱えるわけです。
皇紀を採用した安田生命保険の先見の明
実は安田生命は1940年を起点にプラスとマイナス99年を保持していたのです。メインフレームでいうところのパック10進数だと、1バイトで正負2桁の数字を保持できる方式で1841年から2039年まで、199年間の年の情報を持てます。1841年は伊藤博文が生まれた年で、1970年代というシステム化した年からすると十分古い年から、70年近く先まで持つ2039年まで1バイトで扱えるわけです。
40年先送りできただけなのに「先見の明」とまで言うこの感覚が判らない。1971年時点で平均寿命が男でも70歳超えているのに。#ちょうど俺も寿命になる頃だ。安田生命には入っていなかったとは思うが...
何がなんでも１Byteにこだわるなら、パック10進じゃなく符号付バイナリでさらにあと28年先延ばしできたのに。
> 40年先送りできただけなのに「先見の明」とまで言うこの感覚が判らない。開発された1970年代から見て、30年弱で問題が発生するところを70年弱と倍以上に延ばせたのなら十分な成果だと思うけど。
2040年までの間には、どのみち深刻な2038年問題の対応がありますしね。先送りのレベルとしては微妙にうまい方法です。
この手の設計の逃げを考え付く事自体は難しくありませんが、それを大規模なシステムで仕様として入れ込んでしまう度胸とちゃんと手順を踏んで承認を得るのは結構難しい。
開発された1970年代から見て、30年弱で問題が発生するところを70年弱と倍以上に延ばせたのなら十分な成果だと思うけど。
対象は生命保険業務なんでしょ？ 加入者の寿命のタイムスパンで考えないといけないシステムじゃないのですか？保険請求したら、"-99年間保険料が未納です"とか言われかねない。そんなことになって初めてシステムを見直そうにも誰もメンテナンス出来そうもないし。そんなリスクを享受してもいいだけの1Byteですか？
通常年内決済のシステムが、予想外に長期間使われ続けてきたというのとは訳が違うとおもうのですが。
先生! 勅令によると閏年の計算で皇紀から660を減じたりする理由がさっぱりわかりません!# 本当はもちろんわかってるのでAC
先頭１桁は実は符号ビットかもしれない先頭桁は符号ビットだから削除↓１だとマイナス↓マイナスの金額なんてありえないから絶対値を格納するように改造（但しこの処理はドキュメントには記載なし）
とか想像してみる。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
不思議UI (スコア:1)
単純に不足桁分の0を後ろに追加してしまうだけならまだ分からんでもないのだが、
(タレコミにもあるけど)先頭の1を消してしまうというのはどういう作りなんだろう？
Re: (スコア:0)
【西暦を採用することは利用者に見えないところでもＮＧ】
→でも明治＜大正＜昭和＜平成でソートしたい
→先頭の１桁を和暦記号として取り扱うというＵＩがあるです。
Re:不思議UI (スコア:1, 参考になる)
先頭１桁の和暦記号は、明治＝Ｍ、大正＝Ｔとかではなく、明治＝１、大正＝２、昭和＝３と振っておくです。
役所の書類は和暦で表記されるので、書類をコンピュータに入力するＵＩも和暦である必要があります。
この方式は、和暦を直接テンキーから手を離さずにパンチ可能な方法として一般的と思われます。
Re:不思議UI (スコア:1)
申請書類なんかで「『1.明治 2.大正 3.昭和 4.平成』で番号に○を付けろ」みたいなのは良くあるので
日付項目であればそれなりに納得いくのですが、この場合は金額(数値項目)ですからねえ。謎だ。
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
それまでに皇統断絶してるだろっつー不敬なシステムだなw
Re:不思議UI (スコア:1)
それまでにシステムの方に寿命がきている自信があるのでしょう。
#まんま2000年問題を彷彿とさせるけど、今システム設計する立場だったら私も自信あるな。
#そーとー長く見て50年もののシステムだったとしても、それまでにその回数代替わりする状況って、多分日本が終わってる。
Re:不思議UI (スコア:1)
一世一元の詔のシステム自体が変わるという発想も必要では？
これが流石に、「何年かのうちにすごい宗教家が出てきて、BC, AD使わなくなるよ」というのなら杞憂だと思いますが、
歴史的には現状のシステムの方が短いので、突拍子もないとまでは言えないですし。
Re: (スコア:0)
>一世一元の詔のシステム自体が変わるという発想も必要では？
オフトピだけど、そもそもそんな歴史も大してない方法に何拘っているのか解らん。
前陛下なんて末年は体調が良くなかったので本当なら引退してしまえば良いのにと思っていたのだが。
流石に思い付きで元号を替えられると困るだろうが、強制的に国民の意識を向けるのには良いと思うんだ。
来年あたり、大震災からの復興の年と成る様に希望を込めてとか、どう？
Re:不思議UI (スコア:1)
> 一世一元の詔のシステム自体が変わるという発想も必要では？
まったく必要ないです。
何故なら、そうなれば元ACの想定する「不敬」を気にする必要がなくなるから。
（視野狭窄的回答）
何故なら、それは十分に変事なのでシステムの改修費用、期間を別途貰って対応できるから。
（理想論的回答）
何故なら、中途半端に対応可能にしておくと
「こんな事もあるわけですし、年月日は西暦で扱うように変更しましょう」
と言ってまっとうな仕様に変更する、非常に貴重な機会を無為に失うことになるから。
（逆説的回答）
Re: (スコア:0)
毎回、性別項目の定義で設計を悩んでしまう私に良いアドバイスを
Re:性別マスター (スコア:2)
よって、
１：男性 ２：女性 ３：トランスジェンダー ０：ヒ・ミ・ツ
という感じにしてはいかが？
Re:不思議UI (スコア:1)
Re: (スコア:0)
Re: (スコア:0)
空海 [wikipedia.org]は？
Re: (スコア:0)
>【西暦を採用することは利用者に見えないところでもＮＧ】
↓
「内部データは神武皇紀で持てばいいんじゃね? 計算楽だし、法律的根拠もクリアだし」
というようなシステムが実際に存在したとかの伝説もありますね。
Re:不思議UI (スコア:1)
安田生命がそうだったらしいですね。Wikipedia にも記述があるし、
探してみると、こんな記事 [itmedia.co.jp]もありました。
Re:不思議UI (スコア:1, 参考になる)
40年先送りできただけなのに「先見の明」とまで言うこの感覚が判らない。1971年時点で平均寿命が男でも70歳超えているのに。
#ちょうど俺も寿命になる頃だ。安田生命には入っていなかったとは思うが...
何がなんでも１Byteにこだわるなら、パック10進じゃなく符号付バイナリでさらにあと28年先延ばしできたのに。
Re: (スコア:0)
> 40年先送りできただけなのに「先見の明」とまで言うこの感覚が判らない。
開発された1970年代から見て、30年弱で問題が発生するところを70年弱と倍以上に延ばせたのなら十分な成果だと思うけど。
Re: (スコア:0)
2040年までの間には、どのみち深刻な2038年問題の対応がありますしね。
先送りのレベルとしては微妙にうまい方法です。
この手の設計の逃げを考え付く事自体は難しくありませんが、それを大規模なシステムで仕様として入れ込んでしまう度胸とちゃんと手順を踏んで承認を得るのは結構難しい。
Re: (スコア:0)
対象は生命保険業務なんでしょ？ 加入者の寿命のタイムスパンで考えないといけないシステムじゃないのですか？
保険請求したら、"-99年間保険料が未納です"とか言われかねない。そんなことになって初めてシステムを見直そうにも誰もメンテナンス出来そうもないし。
そんなリスクを享受してもいいだけの1Byteですか？
通常年内決済のシステムが、予想外に長期間使われ続けてきたというのとは訳が違うとおもうのですが。
Re: (スコア:0)
先生! 勅令によると閏年の計算で皇紀から660を減じたりする理由がさっぱりわかりません!
# 本当はもちろんわかってるのでAC
Re: (スコア:0)
先頭１桁は実は符号ビットかもしれない
先頭桁は符号ビットだから削除
↓
１だとマイナス
↓
マイナスの金額なんてありえないから絶対値を格納するように改造
（但しこの処理はドキュメントには記載なし）
とか想像してみる。