无论如何,为了实现“正确行动”的轨道,必须随时间存储时区信息.换句话说,如果没有(a)包括时区当时的UTC偏移(注1),或者(b)确保插入这些值的所有逻辑首先转换为a,则认识到日期/时间20130407 14:50是没有意义的.某些固定偏移(很可能是0).没有这些东西,两个给定的时间值是无法比拟的,数据是腐败的. (顺便说一句,后一种方法正在玩火(注2);不要这样做.)

在sql Server 2008中,您可以使用datetimeoffset数据类型直接存储偏移量. (为了完整性,在2005年及之前,我会添加第二列来存储当时的UTC偏移值(以分钟为单位).)

这使桌面型应用程序变得容易,因为这些平台通常具有自动将日期/时间区域转换为本地时间然后格式化输出的机制,所有这些都基于用户的区域设置.

对于Web,这是一种固有的断开连接的体系结构,即使正确设置了后端数据,它也会更复杂,因为您需要有关客户端的信息才能进行转换和/或格式化.这通常通过用户首选项设置完成(应用程序在输出之前转换/格式化事物),或者只是为每个人显示具有相同固定格式和时区偏移量的内容(这是Stack Exchange平台当前所做的事情).

你可以看到如果没有正确设置后端数据,很快就会变得复杂和hacky.我不建议你选择这些路径,因为你最终会遇到更多问题.

注1：

时区的UTC偏移量不固定：考虑区域的UTC偏移量加上或减去一小时的夏令时.区域的夏令时也会定期变化.因此,使用datetimeoffset(或当时的本地时间和UTC偏移的组合)可以获得最大的信息恢复.

笔记2：

这是关于控制数据输入.虽然没有简单的验证传入值的方法,但最好强制执行一个不涉及计算的简单标准.如果公共API期望包含偏移量的数据类型,则调用者将清楚该要求.

如果不是这种情况,调用者必须依赖文档(如果他们读取它),或者计算不正确等等.当需要偏移时,失败/错误模式更少,特别是对于分布式系统(或者甚至只是在不同服务器上的web /数据库,如下所示).

无论如何,存储偏移可以一石二鸟;即使现在不需要,也可以在必要时使用.确实,它占用了更多的存储空间,但我认为这是值得的权衡,因为如果数据从未被记录在首位,那么数据就会丢失.