3

Windows Azure ( http://ipredikt.com )で動作する予測ベースのアプリがあります。私が知る限り、Azure の時計は GMT タイム ゾーンに同期されています。ここに私が遭遇している問題があります:

DateTime 型の CreateDate という DB フィールドがあり、その値を 2011 年 6 月 10 日午前 12 時 30 分に設定したとします。新しい予測が作成されたとき。db テーブルの中をのぞくと、日付が正しく設定されています。この値に触れた​​り、変更したりすることは決してありません。ただし、API で値を読み取り、シリアル化してクライアントに送信すると、2011 年 6 月 9 日午後 5 時 30 分という値の日付が取得されます。(API dll もクラウド上にあり、おそらく DB と併置されています。)

私のクライアント ブラウザは PST (太平洋時間帯) で実行されており、7 時間の違いは PST と GMT の違いによるものと思われます。値をシリアル化するために使用される API コードは次のようになります。

System.Web.Script.Serialization.JavaScriptSerializer シリアライザー = new JavaScriptSerializer();

return serializer.Serialize(dataObject);

これは JavaScriptSerializer オブジェクトのバグですか、それともこのデルタを修正するトリックはありますか? 基本的に、.NET フレームワークがこの値に何らかの形で干渉することは望ましくありません。DB フィールドがそのまま返されるようにしたいだけです。

4

2 に答える 2

2

シリアル化された Json 応答でおそらく発生するのは、「エポックからのミリ秒」形式の日付であり、タイムゾーン情報も含める必要があります。これは、ブラウザーがローカル タイムゾーンを基準にして日付を表示するときに考慮します。

これはすべて正しい動作であるため、バグはありません。あなたの場合、この動作が望ましくないように思われます。

.NET 日付には「Kind」プロパティがあります。これが指定されていない場合は、UTC が想定されます。シリアライザーは、シリアライズ時に「Kind」プロパティを考慮する必要があります。シリアル化の前にオブジェクトのこのプロパティを調べて、DateTimeKind.Local に変更してみてください。

http://msdn.microsoft.com/en-us/library/system.datetime.kind.aspx

または、ブラウザー側でカスタムの逆シリアル化を確認することもできます。この場合、逆シリアル化する前に、シリアル化された日付からタイムゾーンの部分を取り除きます。

于 2011-06-20T02:10:35.943 に答える
2

DateTime オブジェクトを Azure に渡すと、その Kind は Local に等しくなります。
(2011 年 6 月 10 日、午前 12 時 30 分～7 日)

ただし、データベースに保存すると、地域情報は失われます。その後、データベースからこのフィールドを読み取ると、Utc 地域で DateTime が作成されます (2011 年 6 月 10 日午前 0 時 30 分)。

最終的に、クライアントは日時を誤って読み取ります。

この問題を解決するには、いくつかのオプションがあります。

1) メソッド パラメータとデータベースで DateTime を DateTimeOffset に変換します。これにより、ローカル リージョン (つまり PST) がデータベースに保存されることが保証されます。

2）DateTime.SpecifyKind（dateTime、DateTimeKind.Unspecified）を使用します-このようにDateTimeの種類は指定されておらず、その後そのままデータベースに保存されます。

var timeNow = DateTime.SpecifyKind(DateTime.Now, DateTimeKind.Unspecified);
serviceClient.SaveTime(timeNow);
var dateTime = serviceClient.GetTime();
于 2011-06-22T02:27:28.433 に答える