夏令时和时区最佳实践

Question

夏令时和时区最佳实践

我希望能够将这个问题及其答案作为处理夏令时的权威指南，特别是处理实际的变更问题。

如果您有任何要添加的内容，请执行此操作

许多系统依赖于保持准确的时间，问题在于由于夏令时改变时间 - 向前或向后移动时钟。

例如，在订单获取系统中有一个业务规则取决于订单的时间 - 如果时钟发生变化，规则可能不那么明确。如何保持订单的时间？当然有无数的场景 - 这只是一个说明性的场景。

• 你是如何处理夏令时问题的？

• 您的解决方案中有哪些假设？（在这里寻找背景）

同样重要的是，如果不是这样的话：

• 你尝试了哪些不起作用？

• 为什么不起作用？

我会对编程，操作系统，数据持久性和该问题的其他相关方面感兴趣。

一般答案很好，但我也希望看到细节，特别是如果它们只在一个平台上可用。

Answer 1

我不确定我能在上面的答案中添加什么，但这里有几点我：时代的类型您应该考虑四种不同的时间：活动时间：例如，国际体育赛事发生的时间，或加冕/死亡/等等。这取决于事件的时区而不是观众的时区。电视时间：例如，特定的电视节目在当地时间晚上9点播出。在考虑在您的网站上发布结果（比如说“美国偶像”）时很重要相对时间：例如：这个问题在21小时内有一个开放的赏金。这很容易显示重复时间：例如：即使DST发生变化，每周一晚上9点都有电视节目。还有历史/交替时间。这些都很烦人，因为它们可能无法映射回标准时间。例如：朱利安日期，日期根据土星的农历，克林贡日历。以UTC格式存储开始/结束时间戳效果很好。对于1，您需要与事件一起存储的事件时区名称+偏移量。对于2，您需要为每个区域存储本地时间标识符，并为每个查看器存储本地时区名称+偏移量（如果您处于紧缩状态，则可以从IP中获取此值）。对于3，以UTC秒存储，不需要时区。4是1或2的特殊情况，具体取决于它是全局还是本地事件，但您还需要存储在时间戳中创建的内容，以便您可以判断在创建此事件之前或之后是否更改了时区定义。如果您需要显示历史数据，这是必要的。存放时间始终以UTC格式存储时间转换为显示的本地时间（本地由查看数据的用户定义）存储时区时，需要名称，时间戳和偏移量。这是必需的，因为政府有时会改变其时区的含义（例如：美国政府更改了DST日期），并且您的应用程序需要优雅地处理事情...例如：DST规则之前和之后LOST剧集的确切时间戳显示改变。偏移和名称以上的一个例子是：足球世界杯决赛比赛于2010年7月11日19:00 UTC在南非（UTC + 2 - SAST）举行。有了这些信息，我们可以历史地确定2010年WCS决赛发生的确切时间，即使南非时区定义发生变化，并且能够在查询数据库时向当地时区的观众显示。系统时间您还需要使您的操作系统，数据库和应用程序tzdata文件保持同步，彼此之间以及与世界其他地方同步，并在升级时进行广泛测试。您依赖的第三方应用程序未正确处理TZ更改并非闻所未闻。确保硬件时钟设置为UTC，如果您在世界各地运行服务器，请确保其操作系统也配置为使用UTC。当您需要从多个时区的服务器复制每小时轮换的apache日志文件时，这一点就变得很明显了。按文件名对它们进行排序仅在所有文件都使用相同的时区命名时才有效。这也意味着当您从一个框转到另一个框并且需要比较时间戳时，您不必在头脑中进行日期数学计算。此外，在所有框上运行ntpd。客户端永远不要相信从客户端计算机获得的时间戳有效。例如，Date：HTTP标头或javascript Date.getTime()调用。当用作不透明标识符时，或者在同一客户端上的单个会话期间进行日期数学运算时，这些都很好，但不要尝试将这些值与服务器上的内容交叉引用。您的客户端不运行NTP，并且可能不一定有可用于其BIOS时钟的电池。琐事最后，政府有时会做很奇怪的事情：从1909-05-01到1937-06-30，荷兰的标准时间恰好是UTC的19分和32.13秒。使用HH：MM格式无法准确表示此时区。好的，我想我已经完成了。

Answer 2

明确关注点的架构分离 - 准确了解哪个层与用户交互，并且必须更改规范表示（UTC）的日期时间。非UTC日期时间是表示（遵循用户本地时区），UTC时间是模型（对于后端和中间层保持唯一）。另外，决定你的实际观众是什么，你不需要服务什么，以及你在哪里画线。不要触摸异国情调的日历，除非您实际上有重要的客户，然后考虑仅针对该区域的单独的面向用户的服务器。如果您可以获取并维护用户的位置，请使用位置进行系统的日期时间转换（例如.NET文化或SQL表），但如果日期时间对您的用户至关重要，则为最终用户提供选择替代的方法。如果涉及历史审计义务（比如确切知道2月前Jo在AZ支付账单的时间是9月），那么保留UTC和当地时间进行记录（您的转换表将在一段时间内发生变化）。为批量生成的数据定义时间参考时区 - 如文件，Web服务等。假设East Coast公司在CA中有数据中心 - 您需要询问并知道他们使用什么作为标准而不是假设其中一个。不要信任嵌入在日期时间的文本表示中的时区偏移，并且不接受解析和遵循它们。而是始终要求必须明确定义时区和/或参考区域。您可以轻松地接收PST偏移的时间，但时间实际上是EST，因为这是客户端的参考时间，而记录只是在PST中的服务器上导出。