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

前端之家收集整理的这篇文章主要介绍了覆盖ASP.NET WebMethod参数的DateTime序列化前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我正在努力清理大型代码库中的错误,其中没有人关注本地时间与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对象的序列化方式.

解决方法

我经常在许多应用程序,服务和不同平台(.NET,@L_404_0@等)上处理这个问题.请相信我,你不希望假装你不关心时区的长期后果.在追逐许多非常难以修复的错误之后,您会希望得到关注.

因此,您应该捕获正确的时区或强制使用特定的时区,而不是剥离时区.如果您合理,可以修复各种数据源以提供正确的时区.如果它们不受您的控制,则强制它们到服务器的本地时区或UTC.

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

如果你现在正确修复它,它可以很容易和便宜.如果你故意打破它,因为你认为它会更便宜,那么当你不得不解开可怕的混乱时,你将没有任何借口.

请注意,这类似于字符串的常见问题:没有纯文本(没有字符编码的字符串),也没有普通(无时区)时间/日期.假装否则是痛苦和痛苦的根源,以及令人尴尬的错误.

猜你在找的asp.Net相关文章