Convert.ToDateTimeは午後の日付/時間にFormatExceptionが発生するが、我々は次の形式でアプリケーションの解析日付/時刻の値を持つ

Question

値：

2009-10-10 09:19:12.124 
2009-10-10 12:13:14.852 
2009-10-10 13:00:00 
2009-10-10 15:23:32.022 

一つの特定のサーバーの突然のすべて（今日）の任意の解析に失敗し始めました時間13:00:00またはそれ以降。この特定のクライアントには5台のサーバーがあり、問題のあるサーバーは1台だけです。問題のない数百のサーバーを持つ数十の他のクライアントがあります。

System.FormatException: String was not recognized as a valid DateTime. 
at System.DateTimeParse.Parse(String s, DateTimeFormatInfo dtfi, DateTimeStyles styles) 
at System.DateTime.Parse(String s, IFormatProvider provider) 
at System.Convert.ToDateTime(String value, IFormatProvider provider) 
at System.String.System.IConvertible.ToDateTime(IFormatProvider provider) 
at System.Convert.ToDateTime(Object value) 

IはDateTime.Parse（S、CultureInfo.InvariantCulture）にcomapred DateTime.Parseを用いた試験（S、CultureInfo.CurrentCulture）を実行し、問題が唯一のCurrentCultureで現れます。しかし、CurrentCultureは他のすべてのサーバーと同じように "en-US"であり、地域や言語の設定で見つけることのできる違いはありません。

誰もこれまで見たことがありますか？私が調べることに関連する提案？

編集：これまでの回答ありがとうございます。しかし、私はこれを調べるための設定を探しています。何年も働いていて何百もの他のサーバーで動作していると突然動作が変化し、動作を停止する可能性があります。私はすでに次のバージョンでそれを変更しましたが、現在のインストールでこれを修正するための設定変更を探しています。

Answer 1

同じ問題が発生しました。アプリケーションプールをリサイクルするだけです。

Answer 2

何とかカルチャオブジェクトが軍事時間表記を理解していないように聞こえます。私は正直にそこからどこに行くのかは分かりませんが、それはあなたに出発点を与えるかもしれません。

Answer 3

形式が正確にわかっている場合は、アプリケーションに何かを教えてください。の代わりにを使用してください。 （他の人が言っているように、任意のより多くのバリエーションを奪うように、だけでなく、インバリアントカルチャを指定します。）それはあなたに多くのより多くの制御を与える：

using System; 
using System.Globalization; 

class Test 
{ 
    static void Main() 
    { 
     Parse("2009-10-10 09:19:12.124"); 
     Parse("2009-10-10 12:13:14.852"); 
     Parse("2009-10-10 13:00:00"); 
     Parse("2009-10-10 15:23:32.022"); 
    } 

    static readonly string ShortFormat = "yyyy-MM-dd HH:mm:ss"; 
    static readonly string LongFormat = "yyyy-MM-dd HH:mm:ss.fff"; 

    static readonly string[] Formats = { ShortFormat, LongFormat }; 

    static void Parse(string text) 
    { 
     // Adjust styles as per requirements 
     DateTime result = DateTime.ParseExact(text, Formats, 
               CultureInfo.InvariantCulture, 
               DateTimeStyles.AssumeUniversal); 
     Console.WriteLine(result); 
    } 
} 

Answer 4

ソリューションは非常に簡単で、CultureInfo.InvariantCultureを使用しています。唯一の賢明なことであるサンプルデータ。

私はこれが違いを説明していないことを知っていますが、あなたのソフトウェアは本当にUIの中を除いて 'デフォルト'のカルチャに頼るべきではありません。

Answer 5

CultureInfo.DateTimeFormatプロパティの値は何ですか？ According to MSDN：

「ユーザーが を上書きすることを選択するかもしれません 地域と言語のオプション部分のコントロールパネルの でWindowsの 現在のカルチャに関連付けられた値の一部例えば、 ユーザーが選択できます。別の形式で日付 を表示したり、 培養にデフォルト以外の 通貨を使用する。

にUseUserOverrideが真であると 指定された文化がCURと一致した場合Windowsのの 文化を借り、のCultureInfo は のDateTimeFormatInfoインスタンスのプロパティの 設定はDateTimeFormatプロパティによって 、および のNumberFormat プロパティによって返されるのNumberFormatInfo インスタンスのプロパティを返したユーザーを含め、これらのオーバーライドを使用しています。ユーザ設定はのCultureInfoに関連付けられた培養 と互換性がない場合、選択したカレンダーは OptionalCalendarsのいずれでもない場合、 例えば、方法の 結果および値は、プロパティの は未定義です。

DateTimeFormat プロパティの値とNumberFormatプロパティ の値は、アプリケーションが アプリケーションにアクセスするまで計算されません。 場合、アプリケーションの実行中にユーザが新しい培養液に電流 培養を変更することができ、次いで アプリケーションはDateTimeFormat又は のNumberFormatプロパティにアクセスし、アプリケーションが代わりの上書きの新しい培養 ためのデフォルト値を取得します オリジナルの文化。オリジナルの現在の 文化のための オーバーライドを維持するには、アプリケーションが現在の 文化を変更する前に DateTimeFormatとのNumberFormat プロパティにアクセスする必要があります。」

をそれが一部のユーザー設定がこれをオーバー乗っているだろうか？

Answer 6

それは野生の推測だが、多分この一連のイベントのようなものが問題を引き起こしている可能性があります：

1. 管理者は続きに入りますすべてのサーバーでPanel Internationalの設定を変更し、「HH：mm：ss」から「hh：mm：ss tt」に変更します。
2. 管理者は、サーバーの1つのみでアプリケーションプール（またはIISサービス、またはマシン）をリサイクルします。

リサイクルされたサーバー上のすべての新しいASP.NETワーカースレッドに、変更された時刻形式が表示され、そのDateTime.Parseメソッドが失敗します。ただし、他のサーバーが依然として元のワーカースレッドを使用している場合は、現在のカルチャの変更がまだ検出されていませんDateTimeFormatInfo。

非常に起こりそうなシナリオですが、もう一度、あなたは非常に起こりそうもない状況です。すべてのサーバー上の関連するアプリケーションプールをリサイクルし、変更があるかどうか確認できます。

Answer 7

Windows 2003サーバーで実行されているC＃.NET 2.0 Webサービスがあります。そのサービスは2年以上続いています。私たちは最近、そのアプリケーションでエラーが発生したことを確認しました。エラーメッセージは「文字列が有効なDateTimeとして認識されませんでした」です。別のWeb servieは、日付を返し、エラーが発生している場合は、その関数は、関数が

を返し

「2010年5月10日午前12:00:00」

のような値を返す必要があります

「2010年5月10日午前12時00分00秒」

間違ったリターンが白末尾にスペースなしAMを持っています。

この問題は、数週間後に数回消えて現れました。 Windowsのログを調べた後、エラーの開始時刻と終了時刻がアプリケーションプールのリサイクルと一致して（1〜2分以内に）、デフォルトで29時間ごとに設定されていることがわかりました。この問題は、本番Webサーバーでのみ発生し、開発サーバーやテストサーバーでは発生しませんでした。私たちはサーバーを交換しようとしましたが、1ヶ月間はエラーはありませんでした。今度はエラーが再開しました。私たちは手動でプールをリセットし、問題はすぐに消えました。プールは定期的にリサイクルされるので、これを許容可能な解決策と見なさないでください。プールのリサイクルが必要かどうかは分かりませんが、定期的なリサイクルはアプリケーションのパフォーマンスに役立ちます。

Webアプリケーションは、ParseExact（）既にを使用していますが、フォーマット文字列は次のようになります。

"YYYY-MM-ddHH：MM：ss.0Z"

の代わり

"YYYY-MM-DD HH：MM：SS" が提案する

このスレッドのJon Skeetこれが大きな違いになるかどうかはわかりません。

カルチャの設定も確認しました。

問題はアプリケーションプールのリサイクルから始まることは明らかですが、そのリサイクル中に何が起こっているのかわかりません。ほとんどの場合、リサイクルに悪影響はなく、エラーが発生すると、次のリサイクルは常にエラーを停止しています。

Answer 8

この問題の原因に関する情報が見つかりました。私たちのC＃クライアントは、ビジネス日付（日付のみ）を文字列値としてWebサービスに送信します。 Webサービスは、この文字列をSqlParameterにSqlCommandに渡して、ビジネス日付のdatetimeパラメータを受け入れるストアドプロシージャに渡します。

お客様のシステムが突然動作していませんでした。 SQL Server Profilerを使用してRPC呼び出しを監視し、日付パラメータに突然時間コンポーネントが含まれていることに気付きました。これは日付のみの値、つまり10/27/2012 12:00:00 AMとします。

WAITFOR DELAY '00:01:00'を追加するようにストアドプロシージャを変更しました。このストアドプロシージャを呼び出している間に、Webサービスのメモリダンプを取得しました。

メモリダンプを調べると、パラメータのデータセットにクライアントが正しい日付文字列 "2012-10-25 00:00:00"を渡していることがわかりました。 Webサービスは、ストアドプロシージャを呼び出したときに、これらの日付の変換をどうにか混乱させました。ダンプにSqlCommandが見つかり、ストアドプロシージャのdateパラメータに対応するSqlParameterを調べました。値は「10/25/2012 12:00:00 PM」でした。

すべてのCultureInfoオブジェクトを見ると、「en-US」のロケール1033に「h：mm：ss tt」という長い時間文字列があります。 AMDesignatorは "AM"でしたが、PMDesignatorは空の文字列でした！私は、これは次のコマンドを実行してC＃での悪い日の原因となった検証：

// clear the PM designator 
System.Globalization.CultureInfo.CurrentCulture.DateTimeFormat.PMDesignator = "" 
// this will yield "12/25/2012 12:00:00 " (note the extra space at the end) 
Convert.ToDateTime("10/25/2012").ToString() 

結果は彼の答えで何ブライアン・ベグリーに対応し、「2012年10月25日午前12時00分○○秒」でした。不変の形式を使用すると非常によく似た結果が得られます。

// clear the PM designator 
System.Globalization.CultureInfo.CurrentCulture.DateTimeFormat.PMDesignator = "" 
// this will yield "10/25/2012 12:00:00" 
Convert.ToDateTime("10/25/2012").ToString(System.Globalization.CultureInfo.InvariantCulture.DateTimeFormat) 
// restore the PM designator to "PM" 
System.Globalization.CultureInfo.CurrentCulture.DateTimeFormat.PMDesignator = "PM" 
// this will yield "10/25/2012 00:00:00" 
Convert.ToDateTime("10/25/2012").ToString(System.Globalization.CultureInfo.InvariantCulture.DateTimeFormat) 

は私がのCultureInfoが破損することが原因になっているかを決定するためには至っていません。

注Microsoft is aware of this issueいます。リンクされた記事によれば、それはWindows Server 2003にのみ適用され、利用可能な修正プログラムがあります。