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

接触確認アプリCOCOA、地域ごとの日付フォーマットの違いで利用日数が狂う新たな不具合」記事へのコメント

  • by Anonymous Coward

    日本国内だけで利用されるから、タイムゾーン決め打ちで自前の時刻処理を使ってるんだね

    • by Anonymous Coward

      今回のはいわゆるタイムゾーンのせいではない。逆に自前処理だったら問題は小さかった。
      変数の値をファイル保存/読み込み処理を、何も考えずに開発言語の標準ライブラリにお任せしたからこんな問題が起きた。
      変数の値を自前でファイル保存してればいわゆるタイムゾーンの問題(時差で多少狂う程度の小さな問題)だけで済んだ。

      #極論を言えばxamarinのせい!w

      • by Anonymous Coward on 2021年03月15日 13時17分 (#3994423)

        それがホントならxamarin何やってんのって感じだな

        親コメント
        • Re:決め打ち (スコア:3, 興味深い)

          by Anonymous Coward on 2021年03月15日 13時40分 (#3994444)

          いや、ロケールをデフォルト(実行環境依存)にしていたから起きるわけで、プログラマの責任だよ
          今は発生する場面がなさそうだけど、小数点(カンマとドット)も同じ問題を孕んでる

          全部 ISO 基準にしろよ、と思うかもしれないが、出力結果がどう使われるかは設計次第なわけで、人が読むテキストなのか機械が読むテキストなのかを区別するのはプログラマの責任
          人が読むテキストなら、現地環境で可読性の高い現地ロケールで出力されて欲しいからね

          親コメント
          • by Anonymous Coward

            Dateをシリアライズして保存するのにロケールに依存する必要なんかなくないか?
            「保存用の保存」してロケールに依存しちゃうんじゃxamarinおかしいっしょ
            「表示用の文字列化して保存、読み込んだ後Dateに変換」してるんだったらプログラマがおかしいけど。

            > Ver.1.2.2で混入したものとみられている。
            らしいから、バイナリだった保存を「読めたほうが良いか!」と文字列化/復元に変えてやっちゃった、とかかなぁ

            • by Anonymous Coward

              ぶっちゃけバイナリだからミスしないわけでもないし

            • by Anonymous Coward

              シリアライズ値でロケールに依存しないっていうと、UNIXエポック時間なんかがいいのかな

              シリアライズ元のDate自体がロケールに依存してないのかな。サマータイムとか
              依存してたらプログラム上は表示以外はずっとUNIXエポックのまま扱わない限り問題起きそう

              • by Anonymous Coward

                Unix timeで扱うとバグを生むからこういうライブラリがあるのよ

              • by Anonymous Coward
                まあC#なら標準ライブラリのDateTimeOffset.ToUnixTimeSeconds()/FromUnixTimeSeconds()呼ぶだけですけどね
          • by Anonymous Coward

            ただ単にファイル上での日付の形式を明確にしとけば良かったてだけの話よね。
            悪いのはプログラマ。

        • by Anonymous Coward on 2021年03月15日 15時06分 (#3994498)

          #3994406 はウソですね。.NETの標準ライブラリ関数の使い方が問題です。

          DateTime.ToString メソッド (System) | Microsoft Docs
          https://docs.microsoft.com/ja-jp/dotnet/api/system.datetime.tostring [microsoft.com]

          DateTime.Parse メソッド (System) | Microsoft Docs
          https://docs.microsoft.com/ja-jp/dotnet/api/system.datetime.parse [microsoft.com]

          いずれも引数にロケールを指定して日付⇔文字列の変換が可能です。
          その指定を省略すると現在のロケールに応じた処理となるので今回のような問題が発生します。
          Xamarin関係ないですし、自前でファイル保存する必要もありません。

          親コメント
          • by Anonymous Coward on 2021年03月15日 15時44分 (#3994515)

            某社にいたとき、海外支社から上がってきたプログラムがテストを通らなかったことを思い出した
            現地の単体テストは通っているんだろう、とソースを読んでみたら日付を文字列化して月名で判断していた orz

            つまり、ToString()すると英語圏だと "15-Mar-2021" とかになる
            そこに"Jan"が含まれていれば1月、"Feb"が含まれていれば2月、"Mar"が含まれていれば3月……のように月を調べていた
            日本語環境だとToString()で "2021/03/15" や "2021年3月15日" になるから英語名が含まれない
            どの条件にも引っかからないわけ

            # なんのことはない、月をDateTime.Monthで取るよう修正した

            親コメント
            • by Anonymous Coward

              "Jun"が7月で"Jul"が6月になるのがお約束

          • by Anonymous Coward

            ToString("yyyyMMdd")のようにしていればロケールのことを忘れてても普通に動いた。これが自前処理
            ToString()のように「何も考えずに」お任せすると今回のような問題が起きる。

            • by Anonymous Coward

              引数なしのtostringは人間が読める自然な形式に変換するものです。
              もっと言うと表示用の文字列に変換するものです。
              つまり何も考えず誤用した結果です。

              • by Anonymous Coward

                時間が関わるプログラムは素人だけど(というか素人だからこその疑問だけど)、日時を何も考えずに取り出してきたらただ一つの数値が出てくるようなものじゃないんだね?
                NTFSみたいに1601年1月1日0時0分0秒から何100ナノ秒経過したかを示す整数値とか、Excelみたいに1900年1月1日(or 1904年)から何日経過したかを示す実数値とか、そういうのがデフォルトだと思ってたわ。

                # 科学的なプログラムならかじったことあるけど、月曜日に計算した場合と金曜日に計算した場合とで結果が変わるようにプログラムする機会なんて無いからね。

              • by Anonymous Coward

                内部的にはそういう数値だよ。
                C#は日付の数値を日付文字列に変換したり、逆に日付文字列を日付の数値として読み込んでくれる機能がある。その機能を使って起きた問題。

              • by Anonymous Coward

                曜日は問題じゃないの経過時間の計算とかで困るの。エクセルも表面上はOSのタイムゾーン見てるから気をつけないとハマる。

          • by Anonymous Coward

            Xamarinが悪い!に持っていきたいコメをちょくちょく見かけますね。
            使われると都合悪い人?

犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー

処理中...