3

我有一个基于预测的应用程序，它在 Windows Azure ( http://ipredikt.com ) 上运行。据我所知，Azure 的时钟与 GMT 时区同步。这是我遇到的一个问题：

假设我有一个类型为 DateTime 的名为 CreateDate 的数据库字段，我将其值设置为 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();

返回序列化程序。序列化（数据对象）；

这是 JavaScriptSerializer 对象中的错误还是有修复此增量的技巧？基本上，我不希望 .NET 框架以任何方式干扰这个值，我只希望 DB 字段按原样返回。

4

2 回答 2

2

序列化的 Json 响应中可能出现的日期是“自纪元以来的毫秒数”格式的日期，并且还应该包括时区信息，然后浏览器在显示相对于本地时区的日期时会考虑这些信息。

所有这些都是正确的行为，所以没有错误。在您的情况下，您似乎不希望这种行为。

.NET 日期具有“种类”属性。如果未指定，则假定为 UTC。序列化程序在序列化时应考虑“种类”属性。尝试在序列化之前检查对象上的此属性，并将其更改为 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:30am-7）

但是，当您将其保存到数据库时，区域信息会丢失。随后，当从数据库中读取此字段时，它会使用 Utc 区域创建 DateTime（2011 年 6 月 10 日，凌晨 12:30 0）

最终，您的客户会错误地读取日期时间。

有几个选项可以解决此问题。

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 回答