Question

我使用asp.net [WebMethod]将.net对象推送回浏览器上的Ajax调用。对象的一个属性是DateTime类型。

当它到达浏览器时，时间比存储在SQL Server中的时间早7个小时。

好的，所以我的浏览器在秘鲁（GMT-5），服务器在德国（目前是GMT + 2），这就是7小时的来源。

作为修复，我使用Ajax请求在客户端上发送UTC偏移量

d = new Date();
d.getTimezoneOffset();

然后在服务器上我找出那里的偏移量：

  // get a local time zone info
  TimeZoneInfo tz = TimeZoneInfo.Local;

  // get it in hours
  int offset = tz.BaseUtcOffset.Hours;

  // add one hour if we are in daylight savings
  if (tz.IsDaylightSavingTime(DateTime.Now))
  {
      offset++;
  }

现在我可以在发送到浏览器之前修复对象中的时间字段。

我真正的问题是，序列化器如何知道7小时？

http请求不包含任何时间信息。

如果我想要存储在数据库中的确切时间，我会问得太多吗？

更新

这是一个例子，数据库中的日期是：2009年10月15日22:00

没有附加TimeZone信息。

当我在我的开发机器上调用我的WebMethod时客户端和服务器显然在同一时区，服务器的JSON是：

{"d":{"TheDate":"\/Date(1255662000000)\/"}}

德国远程服务器的JSON是：

{"d":{"TheDate":"\/Date(1255636800000)\/"}}

在Firebug中看到的JSON相差7小时。在这指出还没有涉及JavaScript。

我有一个想法是asp.net将一个TimeZone附加到会话中，但似乎并非如此。

Answer 1

为了避免奇怪的错误并且必须处理这些问题，您应该始终处理UTC并在最后一刻转换为当地时间。

如果DateTime到达浏览器后如何检查？您确定原始序列化格式不包括作为DateTime对象一部分的偏移量吗？在这种情况下，它可以在当地时间的另一端重建

Answer 2

要回答OP问题，时区信息隐含在转换为JSON / Date（）/格式中，因为它与UTC相关。例如，在我在NY的服务器上，如果我返回DateTime.Parse（“1/1/1970”），它返回/ Date（18000000）/，或者5小时（我们现在在DST中），是自1970年1月1日 UTC 以来的秒数，因为转换说“嘿，这是纽约的1/1/1970 00:00:00，所以它必须是1/1 / 70 05:00:00回到格林威治。“

现在，如果加利福尼亚州的客户收到此日期符号，并简单地从毫秒（例如新日期（18000000））实例化JavaScript日期，浏览器会说，“嘿，这是一个日期对象，我知道是相对于UTC的，我知道我距格林威治8小时，所以必须是12/31/1969 21:00:00。“

因此，这是处理时间的一种非常聪明的方式，因此它在所有时区都是“正确的”，并且所有本地化都由用户的浏览器处理。不幸的是，我们经常只处理一个我们不想成为时区相关的原始日期（例如，生日）。如果我们需要保持相同的日期，我知道有两种方式。

首先，正如您上面所做的那样，是调整时间（虽然我认为您需要在浏览器中执行此操作，如果您希望它在任何时区工作）。

另一种方法是将其作为字符串返回，格式化。这是我通常使用的方法，但我通常与美国客户合作（例如，我可以返回MM / DD / YYYY，他们不会因为美国人而对我生气）。

Answer 3

我刚遇到同样的问题。似乎Json Serializer在系统所在的默认时区中返回日期（基本上忽略了DateTime所在的任何时区）。

例如为：在我的开发机器上，它返回我的机器所在时区的日期（太平洋）;在我们的生产机器上，JSON日期是UTC - 这是服务器设置的时区。

要解决这个问题，在我们的案例中，我们必须通过javascript在客户端手动添加hoursoffset，minutesoffset和夏令时偏移量。

.net JSON序列化程序将本地客户端时间返回给浏览器？

3 个答案: