首先，请认识到，在现代术语中，您应该说 UTC 而不是 GMT。它们大多是等效的，只是 UTC 的定义更精确。保留术语 GMT 以指代英国时区中在冬季月份生效且偏移量为 UTC+0 的部分。

现在来回答你的问题。UTC 不一定是存储所有日期和时间值的最佳方式。它特别适用于过去的事件或未来的绝对事件，但对于未来的本地事件（尤其是未来的重复事件）就不那么有效了。

我最近在另一个答案上写过这个问题，并且是本地时间比UTC更有意义的少数例外情况之一。主要论点是“闹钟问题”。如果按 UTC 设置闹钟，则会在 DST 转换当天提前或延迟一小时醒来。这就是为什么大多数人按当地时间设置闹钟的原因。

当然，如果您正在处理来自世界各地的数据，则不能只存储本地时间。您应该存储一些不同的东西：

• 重复事件的本地时间，例如“08：00”
• 表示本地时间的时区，例如“America/New_York”
• 重复模式，采用对应用程序有意义的任何格式，例如每天、每两周或每月的第三个星期四等。
• 下一个即时 UTC 日期和时间等效值，尽你所能预测它。
• 也许，但并非总是，未来事件 UTC 日期和时间的列表，预测出未来的某个预定义时间段（可能是一周，也许是 6 个月，也许是一两年，具体取决于您的需要）。

对于最后两个，请了解，如果负责该时区的政府决定更改任何内容，则任何本地日期/时间的 UTC 等效值都可以更改。由于每年都有多个时区数据库更新，因此您需要制定计划来订阅更新公告并定期更新您的时区数据库。每当您更新时区数据时，都需要重新计算所有未来事件的 UTC 等效时间。

如果您计划显示跨多个时区的任何类型的事件列表，则拥有 UTC 等效项非常重要。这些是要查询以生成该列表的值。

要考虑的另一点是，如果将事件安排在 DST 回退转换期间发生的本地时间，则必须确定该事件是在第一个实例上发生（通常），还是在第二个实例上（有时）发生，或者同时发生在两者上（很少），并在应用程序中内置一种机制，以确保事件不会触发两次，除非您希望它触发。

如果您正在寻找一个简单的答案 - 对不起，但没有答案。跨时区安排未来事件是一项复杂的任务。

替代方法

我有几个人向我展示了一种他们确实使用 UTC 时间进行调度的技术，即他们选择本地时间的开始日期，将其转换为要存储的 UTC，并存储时区 ID。然后，在运行时，它们应用时区将原始 UTC 时间转换回本地时间，然后使用该本地时间计算其他重复时间，就好像它是最初存储的重复时间一样。

虽然这种技术可以工作，但缺点是：

• 如果在运行第一个实例之前更改了本地时间的时区更新，则会中断整个计划。这可以通过为“第一个”实例选择过去的时间来缓解，这样第二个实例实际上是第一个实例。

• 如果时间真的是一个“浮动时间”，应该跟随用户四处走动（例如在手机上的闹钟中），您仍然需要存储最初创建该时间的区域的时区信息 - 即使这不是您想要运行的区域。

• 它增加了额外的复杂性，没有任何好处。我会保留这种技术，以备不时之需，因为你可能有一个仅限UTC的调度程序，你正在尝试将时区支持改造到其中。