パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

世田谷区の通知書類で「平成3元年」との誤表示、和暦の一の位が「1」だった場合「元」に変換する処理だった」記事へのコメント

  • by Anonymous Coward

    本来期待される「和暦が「1」だった場合に「元」に変換する処理」より
    「和暦の1の位が「1」だった場合に「元」に変換する」の処理の方が面倒くさそうなんだけど?
    (それも 31年→元年 ではなくて、 31年→3元年 なんて・・・)
    なんで、あえて面倒くさい処理にしたんだろう?

    実は、「1を全て「元」に変換する」処理だったんではないだろうかと邪推してしまう。

    • by Anonymous Coward

      すでにそこに至った時点で文字列だったんでしょう。
      で、10年以降の上位桁が誤爆しないように"1年"を"元年"に置き換えたと。

      • by Anonymous Coward on 2019年04月16日 16時15分 (#3600153)

        文字列だとしても
        ”01”or" 1"を元にするんじゃいかんのか?

        COBOL固定長でも2桁文字列の比較ぐらいできるだろ。

        なぜ下位1桁だけで判断する必要がある?

        親コメント
        • by Anonymous Coward

          元が"1"だったら"01"で判断じゃ駄目。
          元が"年の数字文字列"のみのフィールドでなかったら"01"でも"1"でも駄目。
          "平成1年~"とか"令和1年~"で年月日全体入っているような対象なら、まあやられそうなミス。

          前が数字じゃない判定?正規表現すら難しい環境の可能性。

          • by heavensgate (21016) on 2019年04月17日 18時01分 (#3600949)
            この場合前に元号がつく「1年」を判定するのだから、
            (明治|大正|昭和|平成|令和)1年を検索して、(括弧の中のマッチしたもの)元年 に変換するような。
            まあ明1年とかやられたらアレですが。
            --
            -- To be sincere...
            親コメント
          • by Anonymous Coward

            全体が文字列なら文字列長+固定桁で判断すればいい話。
            平成1年なら全体が7桁で5桁目を確認。8桁なら ”1”と”01”のどちらかに当たるか。

            このぐらいの事すら思いつかないお前みたいなのがこういうバグ起こすんだろうな。

            • by Anonymous Coward

              まさかUnicodeとか何も考えてないんだろうか。
              やらかしたパターン推測してるだけで他の回避策が思いつかないなんて言ってないだろうに。

            • by Anonymous Coward

              前後に何通りかの文字数の異なる文字列が付いている場合とか、『文字列長+固定桁で判断』できない可能性も簡単に思いつくと思うんだけど。

UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie

処理中...