覆盖ASP.NET WebMethod参数的DateTime序列化

Question

我正在努力清理大型代码库中的错误,其中没有人关注本地时间与UTC时间.

我们想要的是一种全局忽略发送到ASP.NET Web服务和从ASP.NET Web服务发送的DateTime对象的时区信息的方法.我有一个检索操作的解决方案.数据仅在数据集中返回,我可以查找DateTime列并将DateTimeMode设置为Unspecified.这解决了我在数据集内来回传递的所有数据的问题.

但是,DateTime对象也经常作为参数直接传递给Web方法.我想剥离任何传入的时区信息.而不是通过我们的客户端代码搜索和使用DateTime.SpecifyKind(..)来设置所有的DateTime瓦尔为undefined,我想要做某种全球ASP.NET覆盖的监控传入的参数,并剥离出时区信息.

这样的事情可能吗？或者还有另一种更简单的方法来做我想做的事情吗？

只是重申 - 我不关心时区,每个人都处于同一时区.但一对夫妇的用户已经严重的机器配置,错时区等,所以当他们在2008年7月1日,发送,我收到2008年6月30日22:00:00在服务器端它会自动从转换它自己本地时间到服务器的本地时间.

更新:另一种可能性是,如果可以在客户端.NET代码上进行更改,以更改具有Kind'Undefined'的DateTime对象的序列化方式.

Answer 1

我经常在许多应用程序、服务和不同平台（.NET、Java 等）上处理这个问题。请相信我，您不希望假装您不关心时区而产生长期后果。在发现了许多修复起来极其困难且昂贵的错误之后，你会希望自己当时关心过这些错误。

因此，您应该捕获正确的时区或强制指定特定时区，而不是剥离时区。如果可以的话，修复各种数据源以提供正确的时区。如果它们超出了您的控制范围，则强制它们使用服务器的本地时区或 UTC。

一般的行业惯例是强制一切都采用 UTC，并将所有生产硬件时钟设置为 UTC（这意味着服务器、路由器等网络设备等）。然后，您应该在 UI 中转换为用户的本地时区/从用户的本地时区转换。

如果你现在正确修复它，它会很容易而且便宜。如果你故意进一步打破它，因为你认为这样会更便宜，那么当你必须解决这个可怕的混乱时，你将没有任何借口。

请注意，这与字符串的常见问题类似：不存在纯文本（没有字符编码的字符串）这样的东西，也不存在纯（无时区）时间/日期这样的东西。假装不然是许多痛苦和心痛以及令人尴尬的错误的根源。