当我得到一个日期时间字符串,比如说“7/10/2013”,我就是这样做的
Convert.ToDateTime("7/10/2013").ToUniversalTime();
这将在数据库中将其记录为“7/10/2013 4:00:00 AM”.服务器位于美国东海岸(-5).当然,在2013年7月期间,DST仍然被观察到,因此在此期间的偏移为-4,这样额外的4小时4:00:00 AM“记录为UTC.
当我写这篇文章时,它是2014年2月,DST没有生效,所以现在偏移是-5.在我的应用程序中,这是我在我的应用程序中选择的偏移量.
如果我将-5偏移应用于“7/10/2013 4:00:00 AM”,则日期将为“7/09/2013 11:00:00 PM”.
哪一天是错的,有一天关闭.
问题#1
那么如何才能正确转换UTC时间呢？这意味着,当用户现在在2014年2月加载我的应用程序时(目前时区偏移为-5),7/10/2013 4:00:00 AM应该仍然是2013年7月10日,而不是2013年9月7日.
令我困惑的是,因为.ToUniversalTime()考虑了服务器DST,是否存在一个硬盘“通用时间”,它不受服务器所在位置的影响？
问题2
当我在西海岸和东海岸都有服务器,写入数据库时会发生什么？如果记录的UTC时间是基于东海岸还是西海岸,应用程序如何判断？
基本上,代码怎么说,“7/10/2013 4:00:00 AM”是在东海岸创建的UTC时间(表示美国东海岸的7/10/2013 00:00:00 AM)和不是西海岸的服务器(这表明它是美国西海岸的7/09/2013 20:00:00 pm)？
对不起,如果这听起来很愚蠢.任何建议都表示赞赏.
==========最终编辑,我目前的解决方案===============
MiMo的回答很有意义.我对两件事感到困惑.
>数据库中存储的UTC时间对服务器意味着什么？
>服务器的时间与应用程序用户的关系是什么？
我的应用程序可以被来自不同时区的用户使用,有些用户与服务器位于同一时区,有些则不是.有些旅行,所以即使它们与服务器位于同一时区,它们也可能一直落在不同的时区.我的应用程序允许他们选择他们所在的时区,并适当地反映时间.
最初,我只是从数据库中获取UTC时间并从中减去用户的时区偏移量.正如Mimo所说,这是错误的.原因可以在我上面的帖子中看到.
我最初的解决方案是立即获取服务器的时区偏移并使用它来加减速,这也是错误的.截至2013年7月10日,当时服务器的偏移量为-4.目前,在2014年2月,服务器时区偏移为-5.解决方案当然是使用.ToLocalTime()
在我深入研究Mimo关于如何使用TimeZone.ToLocalTime()的建议之前,我就采取了以下措施来暂时解决问题.
>从数据库中获取UTC日期并转换为.ToLocalTime,这是服务器显示的内容.所以到服务器,7/10/2013 4:00:00 AM成为7/10/2013 12:00:00 AM.
>获取服务器时区偏移量.目前显示-5,因为它在美国东海岸.
>获取用户的时区偏移量.对于西海岸,用户现在选择-8.对于东海岸,用户现在选择-5.
>获取用户时区和服务器时区之间的差异.西海岸是-3.东海岸是0.
>从7/10/2013 12:00:00 AM减去差异,因此西海岸的截止日期为7/09/2013 21:00:00 PM,东海岸的截止日期为7/10/2013 12:00:00 AM .
全对了.
非常感谢你们.现在是时候深入了解TimeZone.ToLocalTime()并看看我是否可以减少步骤2-5.
解决方法
如果您有连接到服务器的客户端(例如Web浏览器),您最终希望将日期/时间转换为客户端的本地时间,而不是服务器的本地时间.要做到这一点,最好的方法是使用TimeZone.ToLocalTime()：向服务时间区域发送客户端所在的时区,然后直接转换为该时区.
永远不要加/减小时 – 总是通过时区并使用TimeZoone.ToLocalTime().当涉及DST时,添加/减去小时将不起作用.
请注意,无法从浏览器内部获取当前(本地)时区.如果您的客户端是浏览器,您需要从某种配置中获取时区或让用户输入它.
另请注意,一旦您开始处理不同的时区,您不再只有日期 – 您始终必须处理完整的日期时间：如果您剥离或松开时间部分,则所有转换将不再起作用.
关于问题2：UTC时间是通用的,不是基于任何特定时区,因此一旦转换为UTC,您就不必再担心服务器的时区了.
