アカウント名:
パスワード:
githubに不具合原因が書いてあるので詳細割愛しますが、WindowsとLinuxで取得するタイムゾーンの名称が異なることが原因でエラーになっていたようですね。
COCOAはXamarin(.NET)を使用しているのは既知の通りですが、Microsoftのドキュメントに書かれているコードを開発者がそのまま信用して書いてしまったようですね。
当方も.NET Core(現.NET6)でクロスプラットフォーム開発していますが、確かに類似のケースはあり、悩まされることもあります。MicrosoftのドキュメントはどうしてもWindowsベースで書かれているので、落とし穴が多く感じますね。
もっとも、ちゃんと動作確認しろよ!って言われたらぐうの音も出ないと思いますが。一方で、Microsoftもクロスプラットフォーム開発を売りにするならドキュメントをちゃんと書いて欲しいですね。
githubのコメントを読みましたが、違うみたいですよ。
1. Xamarinがそういうタイムゾーン周りの問題を抱えていることを認識していたので、回避するために、JSTからUCTへの変換を処理を、標準関数を使用せずに自前で作成していた。2. 過去のバージョンで、利用規約同意日(JST)の設定ファイルへの保存方法を変更していたのだが、その辺りの変更経緯を正しく認識していなかった。3. したがって、バージョンアップを特定の経緯で行った(あるバージョンを飛ばすなど)環境では、開発者が想定していなかった値が設定ファイルに書き込まれていたが、気がついていなかった。4. 想定していなかった日付をJSTからUTCに変更しようとして、エラーになって、起動しなくなっていた。
失礼いたしました!タイムゾーン周りのプラットフォーム非互換の懸念を回避するために別の手段を取ったこと原因でした。勘違いしてました。訂正有難うございます!
それってクロスプラットフォームとしてのXamarinの出来が悪くて発生した不具合って事では?
MS特化な開発者が「それじゃタイムゾーンを取得してー」TimeZoneConverter.TZConvert.GetTimeZoneInfo("Tokyo Standard Time");Xamarinでエミュレータで動作確認!よしよし動いた動いたってやらかしてエラー
本来はTimeZoneConverter.TZConvert.GetTimeZoneInfo("Asia/Tokyo");
確か、以前起こっていたiOS版が初期化されるバグも、Xamarinの問題でしたよね。
https://it.srad.jp/story/21/02/15/1636231/ [it.srad.jp]
WindowsとLinuxで取得するタイムゾーンの名称が異なることが原因でエラーになっていたようですね。
まったく違います。原因はそれではありません。さてはIssueの最後に付いてるコメント [github.com]だけ斜め読みしましたね?WindowsとLinuxで取得するタイムゾーンの名称が異なることが原因でXamarinではエラーとなるため、Microsoftのドキュメントに書かれているコードを信用せず、自前でタイムゾーンの変換処理を書いたのが原因ですよ。ちゃんと確認するべきは自分の方では?
失礼いたしました!勘違いしてました。訂正有難うございます。出直してきます!
by Anonymous Coward on 2021年04月03日 7時35分 (#4005919)Xamarinが悪い!に持っていきたいコメをちょくちょく見かけますね。使われると都合悪い人?
接触確認アプリCOCOA、地域ごとの日付フォーマットの違いで利用日数が狂う新たな不具合 [srad.jp]
型がある言語とかSchemaキライなWebのウェーイ系じゃない?
型自体が理解できんみたいなヤツが居たし。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
原因を見るとなるほどなぁ…という感想 (スコア:0)
githubに不具合原因が書いてあるので詳細割愛しますが、
WindowsとLinuxで取得するタイムゾーンの名称が異なることが原因で
エラーになっていたようですね。
COCOAはXamarin(.NET)を使用しているのは既知の通りですが、
Microsoftのドキュメントに書かれているコードを
開発者がそのまま信用して書いてしまったようですね。
当方も.NET Core(現.NET6)でクロスプラットフォーム開発していますが、
確かに類似のケースはあり、悩まされることもあります。
MicrosoftのドキュメントはどうしてもWindowsベースで書かれているので、
落とし穴が多く感じますね。
もっとも、ちゃんと動作確認しろよ!って言われたらぐうの音も出ないと思いますが。
一方で、Microsoftもクロスプラットフォーム開発を売りにするならドキュメントをちゃんと書いて欲しいですね。
Re:原因を見るとなるほどなぁ…という感想 (スコア:3, 参考になる)
githubのコメントを読みましたが、違うみたいですよ。
1. Xamarinがそういうタイムゾーン周りの問題を抱えていることを認識していたので、回避するために、JSTからUCTへの変換を処理を、標準関数を使用せずに自前で作成していた。
2. 過去のバージョンで、利用規約同意日(JST)の設定ファイルへの保存方法を変更していたのだが、その辺りの変更経緯を正しく認識していなかった。
3. したがって、バージョンアップを特定の経緯で行った(あるバージョンを飛ばすなど)環境では、開発者が想定していなかった値が設定ファイルに書き込まれていたが、気がついていなかった。
4. 想定していなかった日付をJSTからUTCに変更しようとして、エラーになって、起動しなくなっていた。
Re: (スコア:0)
失礼いたしました!
タイムゾーン周りのプラットフォーム非互換の懸念を回避するために別の手段を取ったこと原因でした。
勘違いしてました。訂正有難うございます!
Re:原因を見るとなるほどなぁ…という感想 (スコア:1)
それってクロスプラットフォームとしてのXamarinの出来が悪くて発生した不具合って事では?
MS特化な開発者が「それじゃタイムゾーンを取得してー」
TimeZoneConverter.TZConvert.GetTimeZoneInfo("Tokyo Standard Time");
Xamarinでエミュレータで動作確認!よしよし動いた動いた
ってやらかしてエラー
本来は
TimeZoneConverter.TZConvert.GetTimeZoneInfo("Asia/Tokyo");
Re: (スコア:0)
確か、以前起こっていたiOS版が初期化されるバグも、Xamarinの問題でしたよね。
https://it.srad.jp/story/21/02/15/1636231/ [it.srad.jp]
Re: (スコア:0)
WindowsとLinuxで取得するタイムゾーンの名称が異なることが原因で
エラーになっていたようですね。
まったく違います。原因はそれではありません。さてはIssueの最後に付いてるコメント [github.com]だけ斜め読みしましたね?
WindowsとLinuxで取得するタイムゾーンの名称が異なることが原因でXamarinではエラーとなるため、Microsoftのドキュメントに書かれているコードを信用せず、自前でタイムゾーンの変換処理を書いたのが原因ですよ。
ちゃんと確認するべきは自分の方では?
Re: (スコア:0)
失礼いたしました!
勘違いしてました。訂正有難うございます。出直してきます!
Re: (スコア:0)
接触確認アプリCOCOA、地域ごとの日付フォーマットの違いで利用日数が狂う新たな不具合 [srad.jp]
Re: (スコア:0)
型がある言語とかSchemaキライなWebのウェーイ系じゃない?
型自体が理解できんみたいなヤツが居たし。