秋季时间变更期间的计划作业

12

我想知道其他人如何处理这种情况。

如果您有工作计划在凌晨1:30运行，该怎么办。在秋天，随着时间的变化，从1:00:00到1:59:59的时间重复进行，因此作业将运行两次。

可以是Windows Task Scheduler，SQL Agent或任何其他计划工具。这些工具中的大多数似乎是基于机器时间而不是UTC时间。如果我告诉它每天晚上UTC时间执行任务，那么我就不会遇到重复的小时问题。

— 尼尔·沃尔特斯
source

1

我找不到任何更多的电流，但希望这带来了曙光在这个问题上你- support.microsoft.com/kb/325413

— joeqwerty

太好了，为什么不发布答案？

— NealWalters

好吧，它并没有真正为您提供解决方案（至少不能从阅读中看出来），但是我认为这将有助于理解该问题。我很乐意发表评论。

— joeqwerty

10

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

我将从非编程角度进行总结：

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

Windows Task Scheduler

Windows不一定做正确的事。请注意如何定义触发器：

Windows Task Scheduler

选中标有“跨时区同步”的框时，则仅由UTC安排任务。（所有时间仍显示为本地时间，但存储为UTC。）因此，这是我之前所说的“绝对”事件。

取消选中该框时，它将使用运行代码的计算机的本地时区。它没有给您指定时区的任何选择，因此，恕我直言，这不是一个很好的实现。

我不确定这是DST的行为，但我会尝试并就此向您回复。它可能会执行我上面描述的操作，但不一定。

SQL代理

SQL Agent调度程序甚至更糟，因为它仅允许您使用本地服务器时间。同样，不能指定任何时区，您也不能指定UTC。

已请求，但未接受。

— 马特·约翰逊·品特
source

因此，最重要的是，使用特定工具SQL Agent和Windows Task Scheduler，您可以进行每次手动更改，对吗？或者有可能，从调度程序运行的代码可能会重新检查UTC时间，然后可能会延迟（秋天），但是除了手动更改之外，没有其他方法可以避免作业不在Spring中运行。或者，也许是一个可以对时间表进行实际重新编程的脚本？

— NealWalters

我用有关Windows Task Scheduler和SQL Agent的信息更新了答案。两者都不完全正确。如果要开发自己的解决方案，则可能需要查看Quartz.net。

— 马特·约翰逊

在短期内，您可以使用Windows Task Scheduler并选中该框来定义要在特定UTC时间运行的任务。但是您可能希望这些是一次性任务，您可以通过自己的代码以编程方式构建该任务，因此您可以将其余部分考虑在内。

— 马特·约翰逊·品脱

另一个很好的答案！

— NealWalters

1

通常不关心。

问一个问题：“如果任务运行两次，该怎么办？”

通常，这无关紧要，因此您无需执行任何操作。如果这很重要，最简单的解决方案是将工作移出受夏令时更改影响的时间。

— 绝望的N00b
source

如果我不在乎，我也不会问。有些事情，有些没有。在2:00，我们有提取文件并将其发送给供应商的作业。我认为2:00不会重复。为了增加保险，我们将移至2:05。我们有备份，智能索引作业等...但是幸运的是，它们稍后出现了。

— NealWalters 2013年

1

@NealWalters我认为这是一个公平的点，要对得起hopelessnoob：如果没有问题，如果一个任务运行两次，那么为什么担心。我不了解您，但是我有很多事情要担心，而不必担心我不需要担心的事情。如果它确实事，那么你应该已经编码它做一些理智检查反正。话虽如此，避免调度计划在时钟返回的确切时间运行肯定是个好主意-这只是在麻烦。

— 罗伯·摩尔

这不是我的选择，我们在早上的那个时间将摘录文件发送到机场，这就是他们想要文件的时间。我们正在使用基于消息的系统BizTalk，因此很难再次检查此类情况。SQL计划程序和Windows任务计划程序不允许每天使用UTC时间，这有点令人失望。

— NealWalters 2013年

1

如您所述，DST结束时，从1AM到2AM之间的时间重复一次；当发生反向更改时（DST的开始），将不会在凌晨2点到凌晨3点之间发生时间（并且您的作业也不会运行）。您最好的选择将是

运行工作时间表到UTC
在转换之外的时间（12:59 AM或3AM）运行作业

— 安德鲁
source