わかりました-少し一口。したがって、私が抱えている問題はこれです-日付部分のみが必要で、タイムゾーンの変換が必要ない有効期限の日付を保存する必要があります。たとえば、有効期限を「2008 年 3 月 8 日」に設定した場合、タイムゾーンに関係なく、その値をすべてのクライアントに返す必要があります。DateTime としてリモート処理する際の問題は、「2008 年 3 月 8 日 00:00」として保存/送信されることです。これは、私の西側の任意のタイムゾーンから接続しているクライアントが変換され、「2008 年 3 月 7 日」に反転されることを意味します。このシナリオをきれいに処理するには?明らかに、文字列として送信すると機能します。他に何か ?ありがとう、イアン
7 に答える
あなたが言及しているリモーティング テクノロジはわかりませんが、これは WCF の実際の問題です。現在、DateTime を xs:DateTime としてシリアル化することしかサポートしていないため、タイムゾーンに関心がない日付のみの値には不適切です。
.NET 3.5 では、新しい DateTimeOffset 型が導入されました。これは、タイムゾーン間で DateTime を転送するのに適していますが、日付のみのシナリオには役立ちません。
理想的には、WCF は、ここで要求されているように、日付をシリアル化するためにオプションで xs:Date をサポートする必要があります。
http://connect.microsoft.com/wcf/feedback/ViewFeedback.aspx?FeedbackID=349215
私はこれを次のように行います。メモリに日付がある場合、またはファイルに保存されている場合は常に、常に UTC の DateTime になります。ユーザーに日付を表示すると、常に文字列になります。文字列と DateTime の間で変換するときに、タイム ゾーンの変換も行います。
この方法では、ロジックでタイム ゾーンを扱う必要はなく、プレゼンテーションでのみ扱う必要があります。
次のように、必要な詳細へのアクセスを提供する構造体の日付を作成できます。
public struct Date
{
public int Month; //or string instead of int
public int Day;
public int Year;
}
これは軽量で柔軟性があり、完全に制御できます。
文字列として送信し、必要に応じて日付型に変換して戻してみませんか?このように、異なるタイムゾーンで変換されることはありません。単純にする。
編集:私はStructのアイデアが好きで、優れた機能を可能にします。
過去にアプリでこれを処理した最も簡単な方法は、日付を yyyy-mm-dd 形式の文字列として保存することです。それは明確で、自動的に翻訳されることはありません。
はい、痛いです…
UTC 時間として送信できます
dateTime1.ToUniversalTime()
タイムスタンプ文字列として送信するのが最も迅速で簡単な方法だと思いますが、ロケールに強制的に時間変換を停止させることを検討することもできます。