夏令时和时区最佳实践 [英] 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 (past) time using a local time value, include the local time offset for this particular time from UTC (this offset may change throughout the year), 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)混淆.他们是两个不同的东西.请参阅时区标签维基.
    • 请勿使用 JavaScript 的 Date 对象在较旧的网络浏览器中执行日期和时间计算，因为 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.)

    测试:

    • 测试时，请确保测试西部、东部、北部和南半球(实际上在全球的每个四分之一，所以有 4 个区域)，同时进行 DST 并且没有进行(给出 8)，以及一个不使用 DST 的国家(另外 4 个覆盖所有区域)，总共 12 个).
    • 测试夏令时的转换，即当您当前处于夏令时，从冬季选择一个时间值.
    • 测试边界情况，例如时区为 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.

    参考:

    • Stack Overflow 上详细的 timezone 标签维基页面
    • Olson 数据库，又名 Tz_database
    • IETF 维护 Olson 数据库的程序草案
    • 时区和夏令时的来源
    • ISO 格式 (ISO 8601)
    • Olson 数据库和 Windows 时区 ID 之间的映射，来自 Unicode 联盟
    • 维基百科上的时区页面
    • StackOverflow 问题标记为 dst
    • StackOverflow 问题标记为 timezone
    • 处理夏令时 - 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

    其他:

    • 游说您的代表结束夏令时的可憎行为.我们总是希望...
    • 地球标准时间
    的大厅

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