アカウント名:
パスワード:
本来期待される「和暦が「1」だった場合に「元」に変換する処理」より「和暦の1の位が「1」だった場合に「元」に変換する」の処理の方が面倒くさそうなんだけど?(それも 31年→元年 ではなくて、 31年→3元年 なんて・・・)なんで、あえて面倒くさい処理にしたんだろう?
実は、「1を全て「元」に変換する」処理だったんではないだろうかと邪推してしまう。
固定長レコードなんでしょ。したがってCOBOLと推測した。
「令和100年問題」の予感
159歳まで生きないからヘーキヘーキ
> 159歳まで生きないからヘーキヘーキこういう安易な思い込み、想定の甘さが、いざ何十年後かに「令和以降は元号いちいち改定するの止めます、令和で200年ぐらい行きます」とかなったときにバグを生み出すんやで。
COBOLスタイルだと既存のプログラムを改変せず1を元に置換するプログラムを追加するのが普通なんですかね?>COBOLerの方
COBOLを馬鹿にする人はCOBOLの知識が無いので無視して良いです。
PL/IはもちろんFORTRANだって固定長が普通なのにな
無視するのはよくないと思うけど…
IEが9から10になるのか何かのタイミングでJavascriptで、JDKが9から10になるのか何かのタイミングでJavaで1桁だけチェックはNGの話はあったので、他の事例にも当てはまる内容でCOBOLを馬鹿にしてるなら、馬鹿なんでしょうな。
俺もそう思う。元々、元年には対応してなくて、「1年」を「元年」にするために、数値から文字列を生成する関数に置換を後から追加したのだろう。
分かりやすいけど、二桁のときは置換しないように書かなければいけないことを考えていなかった。
"平成 1年"を"平成 元年"に変換する場合、4文字目を'1’から'元'に変更するだけなら4文字目だけをチェックする方が簡単ですよ。"平成11年"や"平成21年"を例外にするなら3文字目のチェックも必要だし。
あーなんか最初は1年って仕様だったのを無理押しで対応求められて、仕様も明確でない。元号_1年なのか元号1年なのか元号01年なのかも判らない。あーもう面倒だから1年を元年にしちゃえばーとか徹夜開けのハイな時間に思いついた様に思えた。
つまり元元年の可能性もあったと!?
すでにそこに至った時点で文字列だったんでしょう。で、10年以降の上位桁が誤爆しないように"1年"を"元年"に置き換えたと。
文字列だとしても”01”or" 1"を元にするんじゃいかんのか?
COBOL固定長でも2桁文字列の比較ぐらいできるだろ。
なぜ下位1桁だけで判断する必要がある?
元が"1"だったら"01"で判断じゃ駄目。元が"年の数字文字列"のみのフィールドでなかったら"01"でも"1"でも駄目。"平成1年~"とか"令和1年~"で年月日全体入っているような対象なら、まあやられそうなミス。
前が数字じゃない判定?正規表現すら難しい環境の可能性。
全体が文字列なら文字列長+固定桁で判断すればいい話。平成1年なら全体が7桁で5桁目を確認。8桁なら ”1”と”01”のどちらかに当たるか。
このぐらいの事すら思いつかないお前みたいなのがこういうバグ起こすんだろうな。
まさかUnicodeとか何も考えてないんだろうか。やらかしたパターン推測してるだけで他の回避策が思いつかないなんて言ってないだろうに。
前後に何通りかの文字数の異なる文字列が付いている場合とか、『文字列長+固定桁で判断』できない可能性も簡単に思いつくと思うんだけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
面倒くさくない? (スコア:0)
本来期待される「和暦が「1」だった場合に「元」に変換する処理」より
「和暦の1の位が「1」だった場合に「元」に変換する」の処理の方が面倒くさそうなんだけど?
(それも 31年→元年 ではなくて、 31年→3元年 なんて・・・)
なんで、あえて面倒くさい処理にしたんだろう?
実は、「1を全て「元」に変換する」処理だったんではないだろうかと邪推してしまう。
Re:面倒くさくない? (スコア:2)
固定長レコードなんでしょ。
したがってCOBOLと推測した。
Re:面倒くさくない? (スコア:2)
「令和100年問題」の予感
Re: (スコア:0)
159歳まで生きないからヘーキヘーキ
Re: (スコア:0)
> 159歳まで生きないからヘーキヘーキ
こういう安易な思い込み、想定の甘さが、いざ何十年後かに
「令和以降は元号いちいち改定するの止めます、令和で200年ぐらい行きます」
とかなったときにバグを生み出すんやで。
Re: (スコア:0)
COBOLスタイルだと既存のプログラムを改変せず1を元に置換するプログラムを追加するのが普通なんですかね?>COBOLerの方
Re:面倒くさくない? (スコア:2)
Z9を置き換えるならともかく
Re: (スコア:0)
COBOLを馬鹿にする人はCOBOLの知識が無いので無視して良いです。
Re: (スコア:0)
PL/IはもちろんFORTRANだって固定長が普通なのにな
Re: (スコア:0)
無視するのはよくないと思うけど…
IEが9から10になるのか何かのタイミングでJavascriptで、JDKが9から10になるのか何かのタイミングでJavaで1桁だけチェックはNGの話はあったので、他の事例にも当てはまる内容でCOBOLを馬鹿にしてるなら、馬鹿なんでしょうな。
Re:面倒くさくない? (スコア:2)
Re: (スコア:0)
俺もそう思う。元々、元年には対応してなくて、「1年」を「元年」にするために、数値から文字列を生成する関数に置換を後から追加したのだろう。
分かりやすいけど、二桁のときは置換しないように書かなければいけないことを考えていなかった。
Re:面倒くさくない? (スコア:1)
"平成 1年"を
"平成 元年"に変換する場合、
4文字目を'1’から'元'に変更するだけなら4文字目だけをチェックする方が簡単ですよ。
"平成11年"や"平成21年"を例外にするなら3文字目のチェックも必要だし。
Re: (スコア:0)
あーなんか最初は1年って仕様だったのを無理押しで対応求められて、仕様も明確でない。
元号_1年なのか元号1年なのか元号01年なのかも判らない。
あーもう面倒だから1年を元年にしちゃえばー
とか徹夜開けのハイな時間に思いついた様に思えた。
Re: (スコア:0)
つまり元元年の可能性もあったと!?
Re: (スコア:0)
すでにそこに至った時点で文字列だったんでしょう。
で、10年以降の上位桁が誤爆しないように"1年"を"元年"に置き換えたと。
Re: (スコア:0)
文字列だとしても
”01”or" 1"を元にするんじゃいかんのか?
COBOL固定長でも2桁文字列の比較ぐらいできるだろ。
なぜ下位1桁だけで判断する必要がある?
Re: (スコア:0)
元が"1"だったら"01"で判断じゃ駄目。
元が"年の数字文字列"のみのフィールドでなかったら"01"でも"1"でも駄目。
"平成1年~"とか"令和1年~"で年月日全体入っているような対象なら、まあやられそうなミス。
前が数字じゃない判定?正規表現すら難しい環境の可能性。
Re:面倒くさくない? (スコア:1)
(明治|大正|昭和|平成|令和)1年を検索して、(括弧の中のマッチしたもの)元年 に変換するような。
まあ明1年とかやられたらアレですが。
-- To be sincere...
Re: (スコア:0)
全体が文字列なら文字列長+固定桁で判断すればいい話。
平成1年なら全体が7桁で5桁目を確認。8桁なら ”1”と”01”のどちらかに当たるか。
このぐらいの事すら思いつかないお前みたいなのがこういうバグ起こすんだろうな。
Re: (スコア:0)
まさかUnicodeとか何も考えてないんだろうか。
やらかしたパターン推測してるだけで他の回避策が思いつかないなんて言ってないだろうに。
Re: (スコア:0)
前後に何通りかの文字数の異なる文字列が付いている場合とか、『文字列長+固定桁で判断』できない可能性も簡単に思いつくと思うんだけど。