Elixir DateTime用法及代码示例

具有时区的日期时间实现。

此日期时间可以看作是给定时区的日期和时间的快照。为此，它还包括 UTC 和标准偏移量，以及专门用于格式化目的的区域缩写字段。请注意，不一定保证未来的日期时间存在，因为由于地缘政治原因，时区可能会在未来的任何时间发生变化。有关详细信息，请参阅“作为快照的日期时间”部分。

请记住，在 Elixir 中使用 ==/2 、 >/2 、 </2 和朋友的比较是结构化的，并且基于 DateTime 结构字段。要正确比较日期时间，请使用 compare/2 函数。

开发人员应避免直接创建 DateTime 结构，而应依赖此模块提供的函数以及第三方日历库中的函数。

时区数据库

此模块中的许多函数都需要时区数据库。默认情况下，它使用 Calendar.get_time_zone_database/0 返回的默认时区数据库，默认为 Calendar.UTCOnlyTimeZoneDatabase 仅处理 "Etc/UTC" 日期时间并为任何其他时区返回 {:error, :utc_only_time_zone_database}。

也可以配置其他时区数据库。例如，两个可用选项是：

• tz
• tzdata

要使用它们，首先确保将其作为依赖项添加到 mix.exs 中。然后可以通过配置进行配置：

config :elixir, :time_zone_database, Tzdata.TimeZoneDatabase

或通过调用 Calendar.put_time_zone_database/1 ：

Calendar.put_time_zone_database(Tzdata.TimeZoneDatabase)

请参阅库安装说明中的正确名称。

日期时间作为快照

在第一节中，我们将日期时间说明为“给定时区的日期和时间的快照”。为了准确理解我们的意思，让我们看一个例子。

想象一下，波兰的某个人想安排明年与巴西的某个人会面。会议将在波兰时区的凌晨 2:30 举行。会议将在什么时候在巴西举行？

您可以在一年前的今天使用本模块中的 API 查询时区数据库，它会为您提供当前有效的答案。但是，这个答案将来可能无效。为什么？因为巴西和波兰都可能改变他们的时区规则，最终影响结果。例如，一个国家可能会选择进入或放弃“夏令时”，这是我们每年将时钟向前一小时或向后一小时调整一次的过程。当规则改变时，波兰时间凌晨 2 点 30 分在巴西的确切时间可能会改变。

换句话说，无论何时使用未来的 DateTime，都无法保证您获得的结果将始终正确，直到事件实际发生。因此，当您询问未来时间时，您得到的答案是反映时区规则当前状态的快照。对于过去的日期时间，这不是问题，因为时区规则不会因过去的事件而改变。

更糟糕的是，波兰时间的凌晨 2:30 可能实际上根本不存在，或者它是模棱两可的。如果某个时区遵守“夏令时”，他们将每年将时钟向前移动一次。当这种情况发生时，有一整小时是不存在的。然后，当他们将时钟往回移动时，有一个特定的时间会发生两次。因此，如果您想在这种转变发生时安排会议，您需要明确说明您的确切意思是凌晨 2:30 中的哪一个。对日期和时间敏感的应用程序需要考虑这些场景并将它们正确地传达给用户。

好消息是：Elixir 包含解决这些问题所需的所有构建块。 Elixir 使用的默认时区数据库 Calendar.UTCOnlyTimeZoneDatabase 仅适用于 UTC，它不会观察到这些问题。一旦你带了合适的时区数据库，这个模块中的函数就会查询数据库并返回相关信息。例如，查看 DateTime.new/4 如何根据本节说明的场景返回不同的结果。