datetime - 夏令时和时区最佳实践

Question

关闭。这个问题需要更多focused .它目前不接受答案。












想改善这个问题吗？更新问题，使其仅关注一个问题 editing this post .

3年前关闭。



Improve this question




我希望让这个问题及其答案成为处理夏令时的权威指南，尤其是处理实际转换时。

如果您有什么要补充的，请做

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

例如，在接单系统中的业务规则取决于订单的时间——如果时钟发生变化，规则可能不那么清晰。订单的时间应该如何持久化？当然，场景数不胜数——这只是一个说明性的场景。

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

哪些假设是您的解决方案的一部分？ (在此处查找上下文)

同样重要，如果不是更重要的话:

你试过什么不起作用？

为什么它不起作用？

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

一般答案很好，但我也想查看详细信息，尤其是如果它们仅在一个平台上可用。

Answer 1

答案和其他数据摘要:(请添加您的)
做:

每当您指的是某个确切时刻时，请根据不受夏令时影响的统一标准来保留时间。 (在这方面，GMT 和 UTC 是等效的，但最好使用术语 UTC。请注意，UTC 也称为 Zulu 或 Z 时间。)

相反，如果您选择使用本地时间值保留(过去)时间，请包括该特定时间与 UTC 的本地时间偏移量(此偏移量可能会在一年中发生变化)，以便稍后可以明确解释时间戳。

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

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

如果您以后可能需要修改时间戳，请包含原始时区 ID，以便您可以确定偏移量是否与记录的原始值相比发生了变化。

在安排 future 的事件时，通常首选本地时间而不是 UTC，因为偏移量更改是很常见的。 See answer , 和 blog post .

存储完整日期(例如生日和周年纪念日)时，请勿转换为 UTC 或任何其他时区。

如果可能，请存储在不包括一天中的时间的仅日期数据类型中。

如果此类类型不可用，请确保在解释值时始终忽略时间。如果您不能确定将忽略一天中的时间，请选择中午 12:00 而不是午夜 00:00 作为当天更安全的代表时间。

请记住，时区偏移量并不总是整数小时(例如，印度标准时间是 UTC+05:30，而尼泊尔使用 UTC+05:45)。

如果使用 Java，请使用 java.time适用于 Java 8 及更高版本。

在 ThreeTen-Backport 中，大部分 java.time 功能被反向移植到 Java 6 和 7。图书馆。

在 ThreeTenABP 中进一步适应早期 Android(<26)图书馆。

这些项目正式取代了可敬的Joda-Time , 现在在 maintenance-mode . Joda-Time, ThreeTen-Backport, ThreeTen-Extra 、java.time 类和 JSR 310由同一个人领导，Stephen Colebourne .

如果使用 .NET ，考虑使用 Noda Time .

如果在没有 Noda Time 的情况下使用 .NET，请考虑 DateTimeOffset通常是比 DateTime 更好的选择.

如果使用 Perl，请使用 DateTime .

如果使用 Python，请使用 pytz或 dateutil .

如果使用 JavaScript，请使用 moment.js与 moment-timezone延期。

如果使用 PHP > 5.2，请使用 DateTime 提供的本地时区转换, 和 DateTimeZone类。使用时要小心 DateTimeZone::listAbbreviations() - see answer .为了使 PHP 保持最新的 Olson 数据，请定期安装 the timezonedb PECL 封装； see answer .

如果使用 C++，请确保使用正确实现 IANA timezone database 的库。 .其中包括 cctz , ICU , 和 Howard Hinnant's "tz" library .在 C++20 中，后者被纳入标准 <chrono>图书馆。

请勿使用 Boost用于时区转换。虽然 its API声称支持标准 IANA(又名“zoneinfo”)标识符，它 crudely maps them POSIX 样式的数据，而不考虑每个区域可能具有的丰富变化历史。 (此外，该文件已停止维护。)

如果使用 Rust，请使用 chrono .

大多数业务规则使用民用时间，而不是 UTC 或 GMT。因此，在应用应用程序逻辑之前，计划将 UTC 时间戳转换为本地时区。

请记住，时区和偏移量不是固定的，可能会发生变化。例如，从历史上看，美国和英国使用相同的日期来“前进”和“后退”。然而，在 2007 年，美国更改了时钟更改的日期。这意味着一年中有 48 周，伦敦时间和纽约时间之间的时差为 5 小时，4 周( Spring 3 周，秋季 1 周)时差为 4 小时。请注意任何涉及多个区域的计算中的此类项目。

考虑时间类型(实际事件时间、广播时间、相对时间、历史时间、重复时间)您需要存储哪些元素(时间戳、时区偏移和时区名称)以进行正确检索 - 请参阅“时间类型” this answer .

使您的操作系统、数据库和应用程序 tzdata 文件在它们与世界其他地方之间保持同步。

在服务器上，将硬件时钟和操作系统时钟设置为 UTC 而不是本地时区。

不管前面的要点是什么，服务器端代码，包括网站，永远不应该期望服务器的本地时区是特别的。 see answer .

更喜欢在应用程序代码中逐案处理时区，而不是通过配置文件设置或默认值全局处理。

使用 NTP所有服务器上的服务。

如果使用 FAT32 ，请记住时间戳存储在本地时间，而不是 UTC。

在处理重复事件(例如每周电视节目)时，请记住时间会随 DST 发生变化，并且会因时区而异。

始终将日期时间值查询为 lower-bound inclusive, upper-bound exclusive ( >= ， < )。

不要:

不要混淆“时区”，例如 America/New_York带有“时区偏移量”，例如 -05:00 .他们是两个不同的东西。见 the timezone tag wiki .

不要使用 JavaScript 的 Date对象在较旧的 Web 浏览器中执行日期和时间计算，因为 ECMAScript 5.1 及更低版本具有 a design flaw可能会错误地使用夏令时。 (这已在 ECMAScript 6/2015 中修复)。

永远不要相信客户的时钟。它很可能是不正确的。

不要告诉人们“始终在任何地方使用 UTC”。这个广泛的建议是对本文档前面描述的几个有效场景的短视。相反，对您正在处理的数据使用适当的时间引用。 (时间戳可以使用 UTC，但 future 的时间安排和日期值不应该使用。)

测试:

测试时，请确保测试西部、东部、北部和 Southern 中的国家/地区。半球(实际上在全局的每个四分之一，所以有 4 个区域)，同时进行 DST 并且没有进行(给出 8 个)，以及一个不使用 DST 的国家(另外 4 个覆盖所有区域，总共 12 个)。

测试夏令时的转换，即当您当前处于夏令时，从冬季选择一个时间值。

测试边界情况，例如时区为 UTC+12，使用 DST，使本地时间 UTC+13 in summer and even places that are UTC+13 in winter

测试所有第三方库和应用程序并确保它们正确处理时区数据。

至少测试半小时时区。

引用:

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

其他:

游说您的代表结束夏令时的可憎之事。我们总是希望...

大堂Earth Standard Time