Moment Timezone 指南

指南区域旨在帮助开发人员学习更好地处理日期和时间问题领域，以及 Moment Timezone 库。这些指南专门针对时区概念以及 Moment Timezone 如何处理它们。

有关更通用的日期和时间建议，请参阅核心 Moment.js 指南。

人们经常对时区和 UTC 偏移量之间的区别感到困惑。

核心 Moment.js 文档中有一篇关于此主题的指南，值得先阅读。从逻辑上讲，它属于 Moment Timezone 的指南，但它比本指南部分早了很多年，移动它会破坏互联网上的很多链接。

有关时区与偏移量的详细说明，请参阅 Stack Overflow 标签。

Moment Timezone 通过使用预编译的时区数据增强了核心 Moment.js 功能。

本节介绍数据的来源、其局限性以及现实世界时区规则的一些怪癖。数据格式的技术细节在API 文档中进行了描述。

Moment Timezone 中的所有时区数据均来自IANA 时区数据库（“tzdb”）。Moment Timezone 直接从 tzdb 使用默认数据，仅使用已发布的版本。库所做的唯一更改是将数据转换为自定义 JSON 格式，并可选地限制要使用的数据的年数。

任何对已编译数据文件进行更改但*未*源自 tzdb 版本的拉取请求都将被拒绝。

如果您认为 Moment Timezone 使用的数据不正确，则要遵循的理想操作顺序是

1. 确保您已升级到库的最新版本。我们会尽量密切跟踪 tzdb 版本，因此升级 Moment Timezone 可以解决大多数过时数据的情况。
2. 对于数据计算问题，请在Moment Timezone 问题跟踪器中提出问题。
3. 对于其他问题（例如创建新的时区定义），请搜索tzdb 邮件列表的存档。新的数据更改或时区定义很可能已经在讨论中，但尚未发布。
4. 如果 tzdb 存档中没有任何内容，请发送邮件至[email protected]。

默认情况下，Moment Timezone 包含IANA 时区数据库（“tzdb”）中的所有数据。这涵盖了一些时区早在 19 世纪的历史数据，以及到 2499 年的未来数据。这通常比大多数应用程序所需的数据要多，因此也有一些预构建的数据包，其年份范围更有限。这些列在项目主页和“使用位置”文档中（或者您可以使用实用函数创建自定义日期范围）。

这些有限包经常出现的一个问题是：**数据范围之外的日期会发生什么？**例如，如果加载的数据仅涵盖 2012 年到 2022 年，并且计算了 2023 年或 2010 年的日期，则该日期的计算 UTC 偏移量是多少？

由于数据格式的结构，数据范围边界处的时区规则被假定为无限期地延伸到过去和未来。这会产生以下行为

• 对于数据范围开始之前的日期，将使用在该时区的数据中找到的第一条规则。
• 对于数据范围结束之后的日期，将使用在该时区的数据中找到的最后一条规则。

例如，假设一个项目正在使用仅涵盖 2015 年到 2025 年的数据文件，并且想要计算 2026 年某个时间在澳大利亚悉尼的时间。

• 时区Australia/Sydney每年 4 月至 9 月的基本（标准）偏移量为UTC+10:00。悉尼的夏令时 (DST) 从 10 月到次年 3 月适用，偏移量为UTC+11:00。
• 由于一年结束时（因此也是数据范围结束时）DST 处于活动状态，因此 DST 偏移量将用于所有未来日期。
• 因此，计算 2026 年 1 月至 3 月的日期将获得偏移量UTC+11:00。这是正确的，但只是*偶然*。计算 2026 年 3 月之后的日期仍将获得偏移量UTC+11:00，即使实际值应为UTC+10:00。这时就会开始出现错误。

解决这些计算问题的最佳方法是确保您使用的数据范围涵盖了项目所需的所有日期。

使用夏令时 (DST) 的时区在实施时间跳转方面有所不同。您不应该假设您从本地时区熟悉的规则适用于其他时区。

开发人员经常遇到的一个区别是，某些时区会在午夜更改时钟。约旦（Asia/Amman）在 2021 年就是一个很好的例子

• 2021-03-25 23:59:59一秒后是2021-03-26 01:00:00（DST 开始）。
• 2021-10-29 00:59:59一秒后是2021-10-29 00:00:00（DST 结束）。

这造成了 3 月 26 日开始时的午夜*未*发生，而 10 月 29 日的午夜发生了两次的情况。

Moment Timezone 会考虑这些奇怪之处，如“解析歧义”文档中所述。但是，当应用程序对时间跳转做出其他假设（尤其是在一天开始时）时，仍然会出现错误。因此请注意，**一天并不总是从午夜开始**。