评论中的讨论线索相当长，但我将尝试回答和解决其中的一些问题（我不会在标题中解决这个问题，因为我相信这在Go语言中并不简单）。

• 事实上，未来的活动安排应该根据活动发生的时区--通常不是UTC。
• 时区标识符永远不会被删除或重命名（很少有例外）。一旦引入，标识符将在TZDB中无限期地保留为Zone或Link。因此，您不需要检查时区是否仍然存在。（Windows时区ID也是如此。）
• DST只是选择正确偏移量的一个方面，标准时间也可能发生变化，但是所有这些都封装在tzdb本身中，您不需要关心创建事件时哪个版本的tzdb有效。

在大多数情况下，解决此问题的一般方法是：

• 存储事件的计划本地日期、时间和时区ID（相对于事件的时区为本地）。

示例：2030-12-31T00:00:00[America/New_York]

• 在创建事件时，还要计算UTC值（或等效的DateTimeOffset值）并将其存储在单独的字段中，以便您确切地知道何时触发事件：

示例：2030-12-31T05:00:00Z（或2030-12-31T00:00:00-05:00）

• 定期检查您的UTC等效时间是否正确。这可以在日常维护任务中进行，也可以在应用程序启动时进行，还可以在事件发生前（也可以在事件发生前一小时进行）进行，或者在所有这些情况下进行。

只有当设备上的时区数据发生更改以给予新的偏移量时，偏移量才会与预计的不同。例如，假设美国立法者在此事件发生前的某个时间成功地使DST永久化。那么，相同事件的等效UTC时间现在将是2030-12-31T04:00:00Z（或2030-12-31T00:00:00-04:00）。
在这种情况下，如果事件的UTC时间发生了变化，请更新它，但事件的原始本地时间通常不应被修改。人类倾向于根据本地时间安排事情，而不是根据UTC时间。
了解TZDB版本给您带来的唯一好处是，您可以减少执行最后一步的频率--只有在知道数据发生了变化时才执行。我认为这是一种优化--通常不需要。

• 如果没有对时区定义进行这样的法律的修改，仅仅是按计划开始/停止夏令时并不是担心这一点的理由。这一点已经通过首先使用TZDB得到了解释。
• 如果事件是“重复发生的”（比如每天上午10：00的会议），那么每次发生可能有不同的偏移，但是本地时间将是一致的，并且不需要更新TZDB来计算它。