あなたが取り組んでいる文化の長い日付形式は、おそらく @VimalStan によって提案されている完全な月名のみを受け入れると思います (いずれかの方法でこれを確認しましたか?)。
あなたがやろうとしていることも (IMHO) 受け入れる必要がありますが、さまざまな文化にこのような「癖」がある可能性があることは承知しています。たとえば、おそらく「mar」は一部の文化ではあいまいですか? (そして、あなたの文化ではあいまいではないかもしれませんが...おそらく、ある文化から別の文化にぶら下がっているコードがあります...文化ルールがどのように実装されているかさえわかりません。有効な提案でさえ...しかし、特定の文化が常に期待どおりに動作するとは限らないという私の指摘は、公正だと思います)。
http://msdn.microsoft.com/en-us/library/system.globalization.cultureinfo.currentculture.aspxを使用して、.NET コンテキストが実行されているカルチャを確認します。Windows ユーザー プロファイルが実行されているコンテキストを確認できます。コントロール パネル (Win 7 の「地域と言語」など) から、長い日付形式を確認してください。
あなたの例は、長い日付形式が「dddd、d MMMM yyyy」である私のPCで正常に動作します。私はオーストラリアにいて、en-au を使用しています。
テストとして、en-au "English (Australia) をカルチャとして使用してみてください (コントロール パネルを使用するか、上記のcurrentculture
リンクに従って [CurrentCulture プロパティを明示的に設定する] の見出しで明示的に設定し、コードが次のように機能するかどうかをテストします。期待される。
期待通りに機能する場合、問題は、たとえば私の文化よりも(そしてたとえばあなたが期待したものよりも)、あなたの文化が構文解析において少し厳密であることを意味していると思います。したがって、月全体を確実に渡すか、ここで を使用して別の回答に従って独自の特定の解析パターンを指定する必要がある場合がありますTryParseExact()
。