夏令时间和时区最佳做法 [英] Daylight saving time and time zone best practices

问题描述

我希望将此问题及其答案提供给处理夏令时的明确指南，特别是处理实际变更。

I am hoping to make this question and the answers to it the definitive guide to dealing with daylight saving time, in particular for dealing with the actual change overs.

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

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

Many systems are dependent on keeping accurate time, the problem is with changes to time due to daylight savings - moving the clock forward or backwards.

例如，一个订单中有一个业务规则系统依赖于订单的时间 - 如果时钟更改，规则可能不是很清楚。订单的时间应如何持续？当然有无数的情景 - 这只是一个例证。

For instance, one has business rules in an order taking system that depend on the time of the order - if the clock changes, the rules might not be as clear. How should the time of the order be persisted? There are of course an endless number of scenarios - this one is simply an illustrative one.

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


• 什么假设是您的解决方案的一部分？ （在这里寻找背景）

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

As important, if not more so:

• 你尝试没有工作？


• 为什么不起作用？

我将对编程，操作系统，数据感兴趣

I would be interested in programming, OS, data persistence and other pertinent aspects of the issue.

一般答案很棒，但我也想看看细节，特别是如果他们只在一个平台上可用。

General answers are great, but I would also like to see details especially if they are only available on one platform.

推荐答案

---

答案和其他数据摘要（请添加您的）

做：

• 每当你指的是一个确切的时刻时间，按照不受夏令时影响的统一标准坚持时间。 （GMT和UTC在这方面是等效的，但是最好使用UTC。请注意，UTC也称为Zulu 或 Z 时间。）


• 如果您选择使用本地时间值保留时间，则包括UTC的本地时间偏移量，以便稍后可以明确解释时间戳。


• 在某些情况下，您可能需要在UTC时间和等效的本地时间之间存储 。通常这是通过两个单独的字段完成的，但有些平台支持一个可以存储在一个字段中的 datetimeoffset 类型。


• 将时间戳存储为数值，请使用 Unix时间 - 这是自 1970-01-01T00：00：00Z （不包括闰秒）。如果要求更高的精度，请改用毫秒。此值应始终基于UTC，无需任何时区调整。


• 如果以后可能需要修改时间戳，请包括原始时区ID，以便您可以确定偏移量是否可以已经从记录的原始值改变。


• 调度未来事件时，通常本地时间是首选而不是UTC，因为偏移量通常会更改。 查看答案和博客。


• 存储整个日期（如生日和周年纪念日）时，不得转换为UTC或任何其他时区。
  
  
  
  
  • 如有可能，请以仅包含日期的日期数据类型存储。
  
  
  • 如果这种类型不可用，请务必在解释值时始终忽略日期。如果您不能放心，时间将被忽略，请选择12:00中午，而不是午夜00:00作为当天更安全的代表时间。
  
  
  • Whenever you are referring to an exact moment in time, persist the time according to a unified standard that is not affected by daylight savings. (GMT and UTC are equivalent with this regard, but it is preferred to use the term UTC. Notice that UTC is also known as Zulu or Z time.)
  • If instead you choose to persist a time using a local time value, include the local time offset from UTC, such that the timestamp can later be interpreted unambiguously.
  • In some cases, you may need to store both the UTC time and the equivalent local time. Often this is done with two separate fields, but some platforms support a datetimeoffset type that can store both in a single field.
  • When storing timestamps as a numeric value, use Unix time - which is the number of whole seconds since 1970-01-01T00:00:00Z (excluding leap seconds). If you require higher precision, use milliseconds instead. This value should always be based on UTC, without any time zone adjustment.
  • If you might later need to modify the timestamp, include the original time zone ID so you can determine if the offset may have changed from the original value recorded.
  • When scheduling future events, usually local time is preferred instead of UTC, as it is common for the offset to change. See answer, and blog post.
  • When storing whole dates, such as birthdays and anniversaries, do not convert to UTC or any other time zone.
    • When possible, store in a date-only data type that does not include a time of day.
    • If such a type is not available, be sure to always ignore the time-of-day when interpreting the value. If you cannot be assured that the time-of-day will be ignored, choose 12:00 Noon, rather than 00:00 Midnight as a more safe representative time on that day.
    
    
    • 不要在时间上使用 Boost 区域转换。而其API 声称支持标准IANA（又名zoneinfo）标识符，它粗略地映射他们对POSIX样式的数据，而不考虑每个区域可能有的变化的丰富历史。 （此外，该文件已经不在维护中。）
    
    
    • Do not use Boost for time zone conversions. While its API claims to support standard IANA (aka "zoneinfo") identifiers, it crudely maps them to POSIX-style data, without considering the rich history of changes each zone may have had. (Also, the file has fallen out of maintenance.)

    不要：

    
    
    • 不要混淆时区，例如 America / New_York 与时区偏移，如 -05：00 。他们是两个不同的东西。请参阅时区标签wiki 。
    
    
    • 不要使用JavaScript的 Date 对象在旧版Web浏览器中执行日期和时间计算，因为ECMAScript 5.1及更低版本具有设计缺陷可能会使用夏令时不正确。 （这是在ECMAScript 6/2015中修复的）。
    
    
    • 不要相信客户的时钟。这可能很不正确。
    
    
    • 不要告诉人们随时随地使用UTC。这个广泛的建议对于本文档前面描述的几个有效的场景是短视的。而是使用适当的时间参考为您正在使用的数据。 （时间戳可以使用UTC，但未来时间安排和仅日期值不应该。）
    
    
    • Do not confuse a "time zone", such as America/New_York with a "time zone offset", such as -05:00. They are two different things. See the timezone tag wiki.
    • Do not use JavaScript's Date object to perform date and time calculations in older web browsers, as ECMAScript 5.1 and lower has a design flaw that may use daylight saving time incorrectly. (This was fixed in ECMAScript 6 / 2015).
    • Never trust the client's clock. It may very well be incorrect.
    • Don't tell people to "always use UTC everywhere". This widespread advice is shortsighted of several valid scenarios that are described earlier in this document. Instead, use the appropriate time reference for the data you are working with. (Timestamping can use UTC, but future time scheduling and date-only values should not.)

    测试：

    
    
    • 测试时，请确保您测试西部，东部，北部的国家和 Southern 半球（实际上在全球每个季度，所以4个地区），同时DST进步而不是（给出8），一个不使用DST的国家（另外4个覆盖所有地区，共计12个）。
    
    
    • 测试DST的转换，即当您正在夏季时，从冬天选择一个时间值。
    
    
    • 测试边界案例，如时区是UTC + 12，与DST，使当地时间 UTC + 13在夏天甚至冬天的UTC + 13的地方
    
    
    • 测试所有第三方库和应用程序，并确保正确处理时区数据。
    
    
    • 至少测试半小时时区。
    
    
    • When testing, make sure you test countries in the Western, Eastern, Northern and Southern hemispheres (in fact in each quarter of the globe, so 4 regions), with both DST in progress and not (gives 8), and a country that does not use DST (another 4 to cover all regions, making 12 in total).
    • Test transition of DST, i.e. when you are currently in summer time, select a time value from winter.
    • Test boundary cases, such as a timezone that is UTC+12, with DST, making the local time UTC+13 in summer and even places that are UTC+13 in winter
    • Test all third-party libraries and applications and make sure they handle time zone data correctly.
    • Test half-hour time zones, at least.

    参考：

    
    
    • 详细的时区标签wiki页面堆栈溢出
    
    
    • Olson数据库，又名Tz_database
    
    
    • IETF草案维护Olson数据库的程序
    
    
    • 时区和DST来源
    
    
    • ISO格式（ISO 8601）
    
    
    • 在Olson数据库之间映射和Windows时区ID，来自Unicode Consortium
    
    
    • 维基百科上的时区页面
    
    
    • StackOverflow问题标签 dst
    
    
    • StackOverflow问题标记为时区
    
    
    • 处理DST - Microsoft DateTime最佳做法
    
    
    • 维基百科上的网络时间协议
    
    
    • The detailed timezone tag wiki page on Stack Overflow
    • Olson database, aka Tz_database
    • IETF draft procedures for maintaining the Olson database
    • Sources for Time Zone and DST
    • ISO format (ISO 8601)
    • Mapping between Olson database and Windows Time Zone Ids, from the Unicode Consortium
    • Time Zone page on Wikipedia
    • StackOverflow questions tagged dst
    • StackOverflow questions tagged timezone
    • Dealing with DST - Microsoft DateTime best practices
    • Network Time Protocol on Wikipedia

    其他：

    
    
    • 您的代表大厅结束可憎的DST。我们总是希望...
    
    
    • 大地标准时间的大厅 / li>
      
    • Lobby your representative to end the abomination that is DST. We can always hope...
    • Lobby for Earth Standard Time

    这篇关于夏令时间和时区最佳做法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！