アカウント名:
パスワード:
元号を取り扱うシステム開発を多数抱えてはいるはずだけど。おそらく社内で共通の仕様なりガイドラインが存在しなくて、場当たり的に各現場で対応していたとすると。
>「洗い出しとテストの負荷が大きい」
となりそうなのは分かり易い。
そして大雑把に「問題点を洗い出せ」的な指示がうえから降ってくるだけだったりして。
月日情報にアクセスせずに1989年→平成元年としているシステムがあります。これを 5/1 改元に対応させるのは大変です。
月日情報が無ければ「平成31年/○○元年」と表示すべきところ、年数の前にしか文字を付加できないとか、文字数が問題になるとかもありそうです。実際問題 1989年1月を和暦で表示させるとか難しいですし。
あと年度表示。2019年度の 5/1 は平成31年度とかも落とし穴になりそうに思います。
# 入力はともかく、出力はすべて西暦で統一してくれればと思うけど…… 無理ですか、そうですか。
全然知らんのですが、実際のところ> 「平成31年/○○元年」と表示すべきところ、とか> 2019年度の 5/1 は平成31年度とかって全部「○○元年」でも通りそうなもんですがダメなの?誰が何の根拠でダメだっていうんだろうそういうの
>誰が何の根拠でダメだっていうんだろうそういうの
会社か関係組織内ヒエラルキーだけで決まりそう。それも理屈や理論からじゃなくて感情だけで(偏見だ)上位からクレームが出たら唯々諾々。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
元号改正に関するガイドライン (スコア:1)
元号を取り扱うシステム開発を多数抱えてはいるはずだけど。
おそらく社内で共通の仕様なりガイドラインが存在しなくて、場当たり的に各現場で対応していたとすると。
>「洗い出しとテストの負荷が大きい」
となりそうなのは分かり易い。
そして大雑把に「問題点を洗い出せ」的な指示がうえから降ってくるだけだったりして。
場当たり的の例:月日情報にアクセスしていない (スコア:4, 興味深い)
月日情報にアクセスせずに1989年→平成元年としているシステムがあります。これを 5/1 改元に対応させるのは大変です。
月日情報が無ければ「平成31年/○○元年」と表示すべきところ、年数の前にしか文字を付加できないとか、文字数が問題になるとかもありそうです。実際問題 1989年1月を和暦で表示させるとか難しいですし。
あと年度表示。2019年度の 5/1 は平成31年度とかも落とし穴になりそうに思います。
# 入力はともかく、出力はすべて西暦で統一してくれればと思うけど…… 無理ですか、そうですか。
Re: (スコア:2)
全然知らんのですが、実際のところ
> 「平成31年/○○元年」と表示すべきところ、
とか
> 2019年度の 5/1 は平成31年度
とかって全部「○○元年」でも通りそうなもんですがダメなの?
誰が何の根拠でダメだっていうんだろうそういうの
Re:場当たり的の例:月日情報にアクセスしていない (スコア:1)
>誰が何の根拠でダメだっていうんだろうそういうの
会社か関係組織内ヒエラルキーだけで決まりそう。
それも理屈や理論からじゃなくて感情だけで(偏見だ)
上位からクレームが出たら唯々諾々。