【发布时间】：2011-03-13 14:04:45
【问题描述】：
我意识到这有点主观，但我希望在这里挑选每个人的大脑来了解他们如何处理多个时区？这里有各种类似的问题，并且接受的答案也同样广泛。
您如何在您构建的应用程序中解决这个问题，您必须克服哪些问题？
【问题讨论】：
标签： mysql sql-server oracle database-design timezone
【发布时间】：2011-03-13 14:04:45
【问题描述】：
您始终将日期/时间存储在一个时区中（十分之九是伦敦时间），并将其在显示器上转换为您用户的时区。这是严格的应用程序级别问题，而不是数据库。
【讨论】：
-
我同意这可能是一个应用程序问题，我也只是想征求其他人的意见。随意重新标记您认为合适的问题。
-
更准确地说，“伦敦时间”通常称为 UTC（通用协调时间，以前称为 GMT 或格林威治标准时间）。
-
在美国，尤其是军方，UTC/GMT也称为祖鲁时间（2010-12-15 12:33Z）。 “Z”也是 Stack Overflow 使用的时间名称。
-
伦敦时间在一年中的大部分时间都与 UTC 不同（当英国夏令时 (BST) 生效时）。最好坚持使用 UTC！
在工作中，我们同时管理多个时钟，不仅是时区，还有一些用于航天器导航的更深奥的时钟。
真正唯一重要的是：无论你选择哪一个，你都与ONE AND ONLY ONE CLOCK保持一致，并且你有合适的时钟转换适用于您需要时间视图在一个不同于您的唯一一个时钟的时钟中。
所以：
One and Only One Clock：选择最简单的一个可以解决您的问题，这很可能是 UTC（有些人会错误地称之为格林威治，但重点仍然存在：零线）。
适当的时钟转换：这取决于您的应用，但您需要提出并回答以下 2 个问题：我需要多大的分辨率？我需要确保我考虑了闰秒吗？一旦你回答了，你就可以选择标准库或更多的 estoreric 库。同样，您必须提出这些问题。
时间视图：当有人选择时间视图（例如太平洋时间）时，只需按需调用适当的时钟转换。
真的，就是这样。
至于库，我使用 Python 编写脚本，但使用 NAIF Spice 库进行任务设计，并使用内部代码进行航天器导航。它们之间的区别只是分辨率和可靠性，因为您已经考虑了您需要考虑的一切（地球自转、相对论、时间膨胀、闰秒等）。当然，您将选择适合您需要的库。
祝你好运。
编辑：
我忘了提一下：不要尝试实现自己的时间管理库 - 使用现成的库。如果您尝试，您可能会成功，但是您的 real 项目将会失败，并且您将只有一个 average 日期时间库可供显示。也许我有些夸大其词，但制作一个可靠的通用日期时间库绝非易事，也就是说，它本身就是一个项目。
【讨论】：
我认为 sql server 2008 新的最佳实践是始终使用 datetimeoffset 数据类型。将日期标准化为 UTC 也是一种很好的做法；但并不总是可行或可取的。
有关更多想法，请参阅此博客文章： http://blogs.msdn.com/b/bartd/archive/2009/03/31/the-death-of-datetime.aspx
【讨论】：
我正在做的一个项目是使用 SQL Server 2005 和 GETUTCDATE() 以 UTC 格式存储日期。
【讨论】：
-
My SQL 代码也是如此。作为构建的一部分，我在 SQL 脚本上运行
grep以查找GETDATE()调用，这是 bad（服务器本地时间）。
您需要维护用户时区信息和所有时区信息。 并始终以 UTC 存储时间。当您想向特定用户显示该信息时，只需访问该用户的时区（为该用户存储）并从存储在 UTC 中的时间中添加或减去该时间量并显示这个.这将是查看信息的用户所在的时区。
【讨论】：
为@kubal5003 +1。
日期和时间的显示总是因文化和时区而变得复杂，因此最好使用最接近用户的层（例如浏览器或本地应用程序）来执行此操作。它还将一些负载从数据库转移到用户的机器上。
但服务器生成的报告有一个例外。所以我存储时区名称/ID（有时只是偏移量/偏差）来查找一天的开始。这可能是系统范围的，也可能是基于每个客户/品牌的。
对于网络应用程序，我通常通过地理位置检测用户的默认时区（这很少出错，因为现在地理数据非常准确）。
【讨论】：
-
是否有一个库可用于从用户 IP/lat,long 获取时区信息？
-
我为奥尔森时区数据编写了一个解析器（通过twinsun.com/tz/tz-link.htm）并将其导入数据库；重要的是
zone.tab文件。我使用 MaxMind 的 GeoCity 数据库将 IP-to-City 与 Lat/Long 进行映射，然后使用 Olson 数据来查找最近的时区。