1

私が抱えている問題が、Umm al-Qura カレンダーでの日時の動作がどのように機能するかを理解していないためなのか、それともバグなのかはわかりません。

基本的に、現在のカルチャに関係なく、内部ユーティリティ クラスが適切に値を解析することを確認するためのテストの作成に取り組んでいます。

以下のコードでは、目標はdt1をdt2に等しくすることです。

    public void ArabicTesting()
    {
        CultureInfo culture = new CultureInfo("ar");

        // Initialize a new datetime (04/01/2048 06:21:01 AM)
        DateTime dt1 = new DateTime(2048, 4, 1, 6, 21, 1);

        // Convert the datetime to a string using arabic cultureinfo
        // string ends up being "17/06/70 06:21:01 ص,"
        string dt2_string = $"{dt1.ToString(culture.DateTimeFormat.ShortDatePattern)} {dt1.ToString(culture.DateTimeFormat.LongTimePattern)}";

        // Parse the string
        DateTime dt2;
        DateTime.TryParse(dt2_string, culture, DateTimeStyles.None, out dt2);
    }

問題は、DateTime.TryParseが datetime を文字列として解析して、同じように見える datetime になるが、予想とは異なる値を持つことです。

何が起こっているかのスクリーンショットをいくつか示します。

dt1 dt2

dt1とdt2の両方のプレビュー値を見ると、同じ「17/06/70 06:21:01 ص」に見えますが、オブジェクトの実際の値はまったく異なります。

これが MS のバグなのか、それともDateTime.TryParseメソッドに正しい文字列値を渡していないためなのか、誰にもわかりませんか?

4

1 に答える 1

1

完全な日付が確実にキャプチャされるようにするLongDatePatternには、代わりに を使用してみてくださいShortDatePattern。

string dt2_string = $"{dt1.ToString(culture.DateTimeFormat.LongDatePattern)} {dt1.ToString(culture.DateTimeFormat.LongTimePattern)}";

2 の結果はこれに基づいて異なるShortDatePattern可能性があります。これは、完全な年 (例) などの解析メソッドでデフォルト値が誤って想定される可能性がある datepart を省略できるためです。どの部分が想定されているか、または想定されていないかは、使用されるカルチャによって異なります。一部のカルチャはおそらくどちらの方法でも機能しますが、他のカルチャには問題があります (アラビア語など)。

この特定のケースでこれが発生した理由をより適切にデバッグするには、2 つの文字列を比較してdt1.ToString(culture.DateTimeFormat.LongDatePattern)、dt1.ToString(culture.DateTimeFormat.ShortDatePattern)日付のどの部分を実行時に現在の日付/時刻のデフォルト値に置き換えることができるかを確認します。

于 2016-06-27T15:45:04.687 に答える