パスワードを忘れた？ アカウント作成
Close
15230220 story
ソフトウェア

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

ストーリー by nagazou
不具合 部門より
あるAnonymous Coward 曰く、

重大な不具合の指摘が放置されていたことでも問題となった厚生労働省の接触確認アプリ「COCOA」だが、GitHubリポジトリの運用が内閣官房情報通信技術（IT）総合戦略室に移管され、PullRequestやIssueを歓迎する方針に変わったことで、OSSコミュニティとしての賑わいを見せ始めている。

そこで3月8日に報告されたIssueのひとつが端末の言語を変更後「プライバシーポリシーの改定」が再表示されるというものだ。話を総合すると、利用端末の地域と言語を日本に設定してCOCOAを利用開始すると日付が「年/月/日 時:分:秒」(yyyy/mm/dd hh:mm:ss)フォーマットで保存されるが、その後、地域と言語を欧州のものに変更してCOCOAを再起動すると日付を「日/月/年 時:分:秒」(dd/mm/yyyy hh:mm:ss)フォーマットで読み込もうとして月と日が入れ替わってしまう。その結果、利用開始日数の表示が狂ったり、同意したはずのプライバシーポリシーが再表示される、あるいは改定されたプライバシーポリシーが表示されないといった現象として表れるという。この不具合は今年2月にリリースされたVer.1.2.2で混入したものとみられている。

なお、先述のIssueは報告者自らcloseしたため、3月9日に別の報告者が各種日付がロケール依存のフォーマットで保存されるとしてIssueを上げ直している。その中で解決策として国際規格ISO 8601フォーマットの利用が提案されているが、既存の日付をどのように引き継ぐかが課題となっているようだ。3月14日現在、IT総合戦略室からの反応はない。

過去にも米国と欧州の日付フォーマットの違いにより、児童ポルノ送信容疑をかけられたスペインの家族が話題になっていることから、スラドの諸兄にはこれらの事例を教訓としてほしい。

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

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

  • 決め打ち (スコア:0)

    by Anonymous Coward on 2021年03月15日 12時08分 (#3994391)

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

    • Re: (スコア:0)

      by Anonymous Coward

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

      ＃極論を言えばxamarinのせい！ｗ

      • Re: (スコア:0)

        by Anonymous Coward

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

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

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

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

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

          シェア
          親コメント

          • Re: (スコア:0)

            by Anonymous Coward

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

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

        • Re:決め打ち (スコア:1)

          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関係ないですし、自前でファイル保存する必要もありません。

          シェア
          親コメント

          • Re:決め打ち (スコア:1)

            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で取るよう修正した

            シェア
            親コメント

  • 素人が良くやる不具合 (スコア:0)

    by Anonymous Coward on 2021年03月15日 12時09分 (#3994392)

    文字コードを考えないとか言語や地域で違う設定を意識しないのとかタイムゾーンを考慮してないとかサマータイムを忘れてるとか素人が良くやる不具合。
    こういう事をやらかす人はプロじゃない。反省して欲しい。

    はいすいません、よく忘れます。

  • サマータイム (スコア:0)

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

    日付でロケールっていうとサマータイムが心配になるけど、大丈夫かね？
    「現在時刻」の拾い方によっては１時間ずれるとかありそうだけど。

    まぁ、日本でしかつかわれない想定で対応しないと明記するのでもいいとは思うが、
    DXだなんだ言ってるんだし、今後を見据えて意識し始めておいてもいいと思う。

    五輪でサマータイムとか言ってたのが懐かしいな。

    # 自分も正しい対処方法はやったことないのでわからんのだけど。

    • Re: (スコア:0)

      by Anonymous Coward

      > 日付でロケールっていうとサマータイムが心配になるけど、大丈夫かね？

      当然サマータイムでも問題が出るコードですね。
      まあ最大1日前後のずれなんで実用上ほぼ問題にならないでしょうけど。
      濃厚接触判定の日付フォーマットはGoogle/Appleが考えてくれてるので大丈夫のはず。

      > まぁ、日本でしかつかわれない想定で対応しないと明記するのでもいいとは思うが、

      日本でしか使われないにしても外国人が使う想定ではあるので日中英の3か国語に対応してるわけで。
      特に中国と行き来する人はロケールを都度切り替えて使っている可能性がある。

    • Re: (スコア:0)

      by Anonymous Coward

      > # 自分も正しい対処方法はやったことないのでわからんのだけど。

      サマータイムを無視した UTC-0 で保存、内部処理をして最終的なアウトプットで UTC やサマータイムを考慮した時刻にする、という形だったかと
      こうしないと巻き戻って重なる時刻の処理とかで色々な問題になる

  • せっかくの国産アプリなのだから (スコア:0)

    by Anonymous Coward on 2021年03月15日 12時17分 (#3994396)

    元号つきの和暦フォーマットで保存したれや。

  • だからISO 8601で扱えとあれほど (スコア:0)

    by Anonymous Coward on 2021年03月15日 12時25分 (#3994402)

    普段Windowsしか使わない輩はこれだから困る。
    どうせRTCも日本標準時になってるような奴だろ。

  • 地域をコロコロ変えるやつおるんか？ (スコア:0)

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

    まぁ、UTCで保存したほうがいいというのはわかるけどよー

    • Re:地域をコロコロ変えるやつおるんか？ (スコア:1)

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

      中国では金盾でGoogleへのアクセスが遮断されている関係上、地域言語が中国なら百度地図(Baidu Maps)を、それ以外ならGoogle Mapsを表示するアプリというものが存在するので、滞在国によってコロコロ変える奴がいないとは言い切れないのがなー

      シェア
      親コメント

    • Re: (スコア:0)

      by Anonymous Coward

      仕事で海外に行く人とかじゃない？
      帰国する人数は分からないけど、訪日した外国人は1月のみで4万6千人くらいなので発生した人はそれなりに居るのでは？

      元々は趣味のソフトだったんだから引き継いだ会社はテストから確認すべきだったよね。

  • 12時間制 (スコア:0)

    by Anonymous Coward on 2021年03月15日 14時07分 (#3994470)

    12時間制でフォーマットで保存した場合はどうなるんだろう。
    「AM8:34:48」とか「PM5:42:34」はまだ良いんだけど、
    「PM12:03:45」「AM12:50:12」「PM0:30:00」「AM0:24:35」を
    上手く処理してくれるかどうか。

    • Re: (スコア:0)

      by Anonymous Coward

      「PM12:03:45」 →24時間制の12時
      「AM12:50:12」 →24時間制の0時
      「PM0:30:00」 →24時間制の12時
      「AM0:24:35」 →24時間制の0時

      ＃例外発生でエラーになりそうだけど例外にならない

    • Re: (スコア:0)

      by Anonymous Coward

      日本人感覚だと、
      「PM12:03:45」夜中
      「AM12:50:12」お昼
      「PM0:30:00」お昼
      「AM0:24:35」夜中
      なんだけど、米国人は
      「PM12:03:45」お昼
      「AM12:50:12」夜中
      「PM0:30:00」お昼
      「AM0:24:35」夜中
      なんだよね。

      • Re: (スコア:0)

        by Anonymous Coward

        それを書くならam/pmは小文字で時刻の後ろにつけないとな！（うるさい

typodupeerror

目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond