約4年前、私はこれに従いました MSDN記事 .Net 1.1およびASMX Webサービス(バックエンドとしてSQL 2000サーバーを使用)で.Netクライアントを構築するためのDateTime使用のベストプラクティス。 DateTimeで発生したシリアル化の問題と、さまざまなタイムゾーンのサーバーで行われたテスト作業をまだ覚えています。
私の質問は次のとおりです。特に、タイムゾーン対応情報を格納するための新しい日時タイプが追加された、WCFやSQL Server 2008などのいくつかの新しいテクノロジーに関する同様のベストプラクティスドキュメントはありますか。
これは環境です:
各レイヤーで使用されるデータ型に関する適切な提案/ベストプラクティスはありますか?
これを行う最良の方法は、常にオブジェクトをUTCとして渡し、クライアントで現地時間に変換することだと思います。そうすることで、すべてのクライアントに共通の参照ポイントがあります。
UTCに変換するには、DateTimeオブジェクトでToUniversalTimeを呼び出します。次に、クライアントでToLocalTimeを呼び出して、現在のタイムゾーンで取得します。
1つの大きな問題は、WCFシリアル化がxs:Dateをサポートしていないことです。これは大きな問題です。日付だけが必要な場合は、タイムゾーンについて心配する必要はありません。次の接続の問題では、いくつかの問題について説明しています。 http://connect.Microsoft.com/wcf/feedback/ViewFeedback.aspx?FeedbackID=349215
ある時点を明確に表現したい場合、つまり日付部分だけでなく、クライアントとサーバーの両方に.NET 3.5がある場合は、DateTimeOffsetクラスを使用できます。または、相互運用性のために、常に日付/時刻の値をUTCとして渡します。
UTC/GMTは、分散環境で一貫しています。
重要なことの1つは、DateTimeプロパティにデータベースの値を入力した後で、datetimeKindを指定することです。
dateTimeValueUtcKind = DateTime.SpecifyKind(dateTimeValue, DateTimeKind.Utc);
Webサービスレイヤーとクライアントレイヤーが.NET DateTime型を使用している限り、次のようなタイムゾーン情報を含むSOAP標準のローカル日付/時刻として適切にシリアル化および逆シリアル化する必要があります。
2008-09-15T13:14:36.9502109-05:00
絶対に、積極的にタイムゾーン自体を知る必要がある場合(つまり、上記は東部標準時または中部夏時間である可能性があります)、それらの部分をそのように公開する独自のデータ型を作成する必要があります。
[Serializable]
public sealed class MyDateTime
{
public MyDateTime()
{
this.Now = DateTime.Now;
this.IsDaylightSavingTime = this.Now.IsDaylightSavingTime();
this.TimeZone = this.IsDaylightSavingTime
? System.TimeZone.CurrentTimeZone.DaylightName
: System.TimeZone.CurrentTimeZone.StandardName;
}
public DateTime Now
{
get;
set;
}
public string TimeZone
{
get;
set;
}
public bool IsDaylightSavingTime
{
get;
set;
}
}
その場合、応答は次のようになります。
<Now>2008-09-15T13:34:08.0039447-05:00</Now>
<TimeZone>Central Daylight Time</TimeZone>
<IsDaylightSavingTime>true</IsDaylightSavingTime>
DateTimeデータ型を保持し、常にGMTとして保存することで幸運に恵まれました。各レイヤーで、GMT値をレイヤーのローカル値に調整します。