アカウント名:
パスワード:
本来期待される「和暦が「1」だった場合に「元」に変換する処理」より「和暦の1の位が「1」だった場合に「元」に変換する」の処理の方が面倒くさそうなんだけど?(それも 31年→元年 ではなくて、 31年→3元年 なんて・・・)なんで、あえて面倒くさい処理にしたんだろう?
実は、「1を全て「元」に変換する」処理だったんではないだろうかと邪推してしまう。
すでにそこに至った時点で文字列だったんでしょう。で、10年以降の上位桁が誤爆しないように"1年"を"元年"に置き換えたと。
文字列だとしても”01”or" 1"を元にするんじゃいかんのか?
COBOL固定長でも2桁文字列の比較ぐらいできるだろ。
なぜ下位1桁だけで判断する必要がある?
元が"1"だったら"01"で判断じゃ駄目。元が"年の数字文字列"のみのフィールドでなかったら"01"でも"1"でも駄目。"平成1年~"とか"令和1年~"で年月日全体入っているような対象なら、まあやられそうなミス。
前が数字じゃない判定?正規表現すら難しい環境の可能性。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
面倒くさくない? (スコア:0)
本来期待される「和暦が「1」だった場合に「元」に変換する処理」より
「和暦の1の位が「1」だった場合に「元」に変換する」の処理の方が面倒くさそうなんだけど?
(それも 31年→元年 ではなくて、 31年→3元年 なんて・・・)
なんで、あえて面倒くさい処理にしたんだろう?
実は、「1を全て「元」に変換する」処理だったんではないだろうかと邪推してしまう。
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...