asp.net - 覆盖 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 代码上进行更改以更改具有“未定义”种类的 DateTime 对象的序列化方式。

Answer 1

我经常在许多应用程序、服务和不同平台(.NET、Java 等)上处理这个问题。请相信我，您不希望假装不关心时区的长期后果。在追查了许多修复起来极其困难且代价高昂的错误之后，您会希望自己在意。

因此，与其剥离时区，不如捕获正确的时区或强制使用特定的时区。如果可以，请修复各种数据源以提供正确的时区。如果它们不受您的控制，则强制它们使用服务器的本地时区或 UTC。

一般行业惯例是将所有内容强制为 UTC，并将所有生产硬件时钟设置为 UTC(即服务器、路由器等网络设备等)。然后，您应该在 UI 中转换为/从用户的本地时区。

如果您现在正确修复它，它会变得容易且便宜。如果你故意进一步打破它，因为你认为这会更便宜，那么当你不得不解开可怕的烂摊子时，你将没有任何借口。

请注意，这类似于字符串的常见问题:没有纯文本(没有字符编码的字符串)这样的东西，也没有纯文本(无时区)时间/日期这样的东西。假装是很多痛苦和心痛的根源，以及令人尴尬的错误。