秋季时间变化期间的预定工作 | 那些遇到过的问题

Mat*_*int 14

考虑到时区和夏令时，按本地时间正确安排未来的任务是一个非常复杂的主题。我之前在这里和这里从 Stack Overflow 的编程角度写过它。

我将从非编程的角度总结一下：

按本地时间而不是 UTC定义您的重复模式。例如，如果您将每日闹钟设置为每天早上 8:00 叫醒您，那么您不希望在夏令时转换后早起或晚起一小时。如果我在美国太平洋时区，则无法安排在 UTC 下午 4:00，因为在转换之后，它必须切换到 UTC 下午 3:00 以保持当地时间上午 8:00 不变。
定义“本地”时间代表的时区。不要假设服务器的本地时区与对最终用户很重要的时区相同。
项目本地时间到UTC日期和时间，您希望事件火灾每次出现。
- 您几乎总是在下一次立即发生时执行此操作，以便您可以使用 UTC 时钟来确定要运行的实际时刻。
- 在某些情况下，您可能还想预测接下来的几个（或多个）实例，例如接下来的 5 个实例，或下一年的所有实例。（这部分对应用程序的要求非常特定。）
制定一个策略（固定的或可配置的），关于如何处理夏令时转换时发生的事件：
- 对于“spring forward”转换，当事件可能不存在时，会出现缺少本地时间的间隙。例如，在美国太平洋时间中，计划在当地时间凌晨 2:00 运行的每日任务在 2014 年 3 月 9 日将不存在。在大多数情况下，您需要将该时间提前（通常为 1 小时） )，因此当天它将在凌晨 3:00 运行，但在下一个实例中将在凌晨 2:00 恢复运行。（但是，您完全有可能为此需要不同的策略。）
- 对于“回退”转换，当出现可能存在两次时，重复的本地时间会重叠。例如，在美国太平洋时间，计划在 1:00 AM 运行的每日任务将有两个可能在 2014 年 11 月 2 日运行的时间。在大多数情况下，您希望在第一次出现 1 时运行:00 AM PDT 并跳过下一次出现在同一日期的 1:00 AM PST。（但同样，您可能需要不同的策略，例如在第二次出现时运行，或同时运行。YMMV）
如果您需要更新时区数据，请准备好重新计算所有出现的 UTC 时间。该IANA /奥尔森TZDB每年推出多项更新，因为世界改变他们的想法对他们的时区偏移和夏令时规则的所有时间的政府。 您不能假设在未来的任何特定时间段内规则不会改变。
- 请务必订阅时区数据发布的公告，并制定将它们应用到您的系统和/或应用程序的流程。
- 在传统的公司环境中，这应该是 IT 运营人员的责任。
- 根据您的环境，您可能会通过tzdatalinux 包更新、Java JRE 或 tzupdater或任意数量的其他渠道获取这些数据。有时是特定于环境的，有时是特定于编程平台的，例如用于 PHP的timezonedb PECL 包等等。
- 微软有自己的时区数据。在 Windows 上，如果您TimeZoneInfo从 .NET使用（例如），您正在使用这些数据。更新来自此处，并且也会通过 Windows 更新自动推出，因此您应该留意那些更新，以便知道何时/是否需要重新计算。
所有这一切的理解，还有就是还是这样一个场景，你会通过UTC只是计划，这是绝对的未来事件。例子：
- 每 X 小时或每 X 分钟运行一次的作业。
- 日出起止时间，或其他天文现象。
- 时间敏感的安全窗口，例如在预先安排的时间向另一方传输敏感信息时。