您总是将日期/时间存储在一个时区中（10个中有9个是伦敦时间），并在显示时将其转换为用户的时区。这是严格的应用程序级问题，而不是数据库问题。

在工作中，我们同时管理几个时钟，不仅是时区，还有一些更深奥的用于航天器导航的时钟。
唯一真正重要的是：无论您选择哪种时钟，您都与一个且仅一个时钟一致，并且您拥有适当的时钟转换，以便在与您的一个且仅一个时钟不同的时钟中查看时间。
因此，

• • 一个且仅一个时钟**：选择一个最简单的方法来解决您的问题，最有可能的方法是UTC（有些人会错误地称之为格林威治，但重点仍然是：零线）。
• • 适当的时钟转换**：这取决于您的应用程序，但您需要提出并回答以下2个问题：我需要多大的分辨率？我需要确保我考虑到闰秒吗？一旦你回答了，你可能会选择标准库或更多的恢复。同样，你必须问这些问题。
• • 时间视图**：当某人选择一个时间视图（比如太平洋时间）时，只需根据需要调用适当的时钟转换。

真的，就是这样。
至于函数库，我使用Python编写脚本，但NAIF Spice Library用于任务设计，内部代码用于航天器导航。它们之间的区别只是分辨率和可靠性，因为它们考虑了你需要考虑的所有因素（地球自转、相对论、时间膨胀、闰秒等）。当然，你会选择适合你需要的函数库。
祝你好运。
编辑：
我忘了说：不要试图实现你自己的时间管理库-使用现成的。如果你尝试，你可能会成功，但你的"真正"项目将死亡，你将只有一个"平均"日期时间库来显示它。也许我被夸大了，但制作一个坚实的，通用的日期时间库是远远不是微不足道的，即，它本身就是一个项目。

我正在进行的一个项目是使用SQL Server 2005和GETUTCDATE()以UTC格式存储日期。

您需要维护用户时区信息和所有时区信息。并且始终以UTC格式存储时间。当您想向特定用户显示该信息时，只需访问该用户的时区（为该用户存储），然后从UTC格式存储的时间中添加或减去该时间量并显示。这将是查看该信息的用户的时区。

我认为SQL Server 2008新的最佳实践是始终使用DatetimeOffset数据类型。将日期规范化为UTC也是很好的实践;但并不总是可行或期望的。
更多想法，请参见此博客文章：Link

+1为@kubal5003.
日期和时间的显示总是因为文化和时区而变得复杂，所以最好使用离用户最近的层（例如浏览器或本地应用程序）来完成这项工作，它还将一些负载从数据库转移到用户的机器上。
但是服务器生成的报告有一个例外，所以我存储时区名称/ID（偶尔只是偏移/偏差）来查找一天的开始。这可能是系统范围的，也可能是基于每个客户端/品牌的。
对于web应用程序，我通常通过地理定位来检测用户的默认时区（这很少出错，因为现在地理数据相当准确）。